Tùy chỉnh tiêu đề HTTP Ủy quyền

81

Tôi cần xác thực khách hàng khi anh ta gửi yêu cầu đến API. Máy khách có mã thông báo API và tôi đã suy nghĩ về việc sử dụng tiêu Authorizationđề chuẩn để gửi mã thông báo đến máy chủ.

Thông thường tiêu đề này được sử dụng cho Basicvà Digestxác thực. Nhưng tôi không biết liệu mình có được phép tùy chỉnh giá trị của tiêu đề này và sử dụng lược đồ xác thực tùy chỉnh hay không, ví dụ:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Bạn có giới thiệu điều này hay không? Hoặc có cách nào tốt hơn để gửi mã thông báo không?

api  http  rest  http-headers  authorization 
— Thomas Watson
nguồn

Câu trả lời:

51

Bạn có thể tạo lược đồ xác thực tùy chỉnh của riêng mình sử dụng Authorization:tiêu đề - ví dụ: đây là cách OAuth hoạt động.

Theo nguyên tắc chung, nếu máy chủ hoặc proxy không hiểu giá trị của tiêu đề chuẩn, họ sẽ để yên và bỏ qua chúng. Đó là việc tạo các khóa tiêu đề của riêng bạn thường có thể tạo ra kết quả không mong muốn - nhiều proxy sẽ loại bỏ các tiêu đề bằng tên mà họ không nhận ra.

Phải nói rằng, có thể là một ý tưởng tốt hơn nếu sử dụng cookie để truyền mã thông báo, thay vì Authorization:tiêu đề, vì lý do đơn giản là cookie được thiết kế rõ ràng để mang các giá trị tùy chỉnh, trong khi đặc điểm kỹ thuật cho các phương thức xác thực tích hợp của HTTP không thực sự nói một trong hai cách - nếu bạn muốn biết chính xác những gì nó nói, hãy xem ở đây .

Điểm khác về điều này là nhiều thư viện máy khách HTTP có hỗ trợ tích hợp cho Digest và Basic auth nhưng có thể khiến cuộc sống khó khăn hơn khi cố gắng đặt giá trị thô trong trường tiêu đề, trong khi tất cả chúng sẽ cung cấp hỗ trợ dễ dàng cho cookie và sẽ cho phép nhiều hơn hoặc ít hơn bất kỳ giá trị nào bên trong chúng.

— DaveRandom
nguồn
10
Rất vui khi biết đó là cách hoạt động của OAuth. Tôi không chắc việc sử dụng cookie sẽ giúp việc triển khai ứng dụng khách đơn giản hơn. Trừ khi khách hàng của bạn là một trình duyệt, khi đó các quy tắc để làm việc với cookie (đường dẫn, thời hạn, v.v.) phức tạp hơn để triển khai trong một ứng dụng khách hơn là chỉ nhớ đặt trường tiêu đề. Hầu hết các thư viện khách hàng làm cho nó khá đơn giản để đặt các tiêu đề chính xác.
— Thomas Watson
2
@ThomasWatson trong khi tôi không thể không đồng ý với bạn về các điểm phạm vi cookie, nó không thực sự quan trọng ở đây. Phạm vi xác thực HTTP (sử dụng Authorization:tiêu đề) là trên mỗi miền. Điều này có nghĩa là nếu bạn đặt miền của cookie thành "miền này" và đường dẫn đến "/" thì nó sẽ có phạm vi giống hệt với phạm vi xác thực HTTP. Tuy nhiên, điều đó thực sự tùy thuộc vào bạn - nhưng như Julian Reschke đã chỉ ra, bạn có thể không nên xác định một sơ đồ xác thực mới trừ khi bạn feel that you have something of generic use- thứ gì đó có thể được sử dụng trong một ứng dụng khác.
— DaveRandom
8

Trong trường hợp yêu cầu CROSS GỐC, hãy đọc phần này:

Tôi đã gặp phải tình huống này và lúc đầu, tôi đã chọn sử dụng AuthorizationHeader và sau đó đã xóa nó sau khi gặp sự cố sau.

AuthorizationTiêu đề được coi là tiêu đề tùy chỉnh. Vì vậy, nếu một yêu cầu tên miền chéo được thực hiện với bộ AutorizationTiêu đề, trước tiên trình duyệt sẽ gửi một yêu cầu trước . Yêu cầu preflight là một yêu cầu HTTP theo phương thức OPTIONS, yêu cầu này loại bỏ tất cả các tham số khỏi yêu cầu. Máy chủ của bạn cần phản hồi với Access-Control-Allow-HeadersHeader có giá trị bằng tiêu đề ( Authorizationheader) tùy chỉnh của bạn .

Vì vậy, đối với mỗi yêu cầu mà ứng dụng khách (trình duyệt) gửi, một yêu cầu HTTP bổ sung (OPTIONS) đã được gửi bởi trình duyệt. Điều này làm giảm hiệu suất của API của tôi. Bạn nên kiểm tra xem việc thêm điều này có làm giảm hiệu suất của bạn hay không. Để giải quyết vấn đề, tôi đang gửi mã thông báo trong các tham số http, mà tôi biết không phải là cách tốt nhất để thực hiện nhưng tôi không thể thỏa hiệp với hiệu suất.

— Abhishek Kumar
nguồn
Tôi cũng đang xem xét chỉ gửi sessionID của mình trong http params. Tại sao bạn nói đây không phải là cách tốt nhất? Có vẻ như nó có lợi thế là chống lại các bức tường lửa tước tiêu đề và cũng chống lại sự suy giảm hiệu suất nguồn gốc chéo. Nhược điểm của nó là gì?
— sấm
1
Điểm bất lợi là chỉ trong trường hợp yêu cầu GET. Tôi đã phải xác thực người dùng bằng cách sử dụng Authorization token(dữ liệu nhạy cảm) cho ứng dụng của mình. Vì lý do tương tự, chúng tôi không nên gửi dữ liệu nhạy cảm trong GET, chúng tôi không nên sử dụng mã thông báo ủy quyền trong params. Theo w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 "Giao thức HTTP KHÔNG NÊN sử dụng các biểu mẫu dựa trên GET để gửi dữ liệu nhạy cảm".
— Abhishek Kumar
Bạn có thể lưu trữ mã thông báo trong cookie nếu bạn không thích tiêu đề. (Đừng nhầm lẫn mã thông báo với id phiên). Lưu ý rằng bằng cách PUT và DELETE, nó sẽ gửi các TÙY CHỌN ... Hãy lưu ý rằng hầu hết thời gian bạn sử dụng một máy khách REST phía máy chủ và một trình duyệt không được coi là một máy khách REST rất tốt.
— inf3rno 15/09/17
5

Điều này hơi cũ nhưng có thể có những người khác đang tìm kiếm câu trả lời cho cùng một câu hỏi. Bạn nên nghĩ về những không gian bảo vệ nào có ý nghĩa đối với các API của bạn. Ví dụ: bạn có thể muốn xác định và xác thực quyền truy cập của ứng dụng khách vào các API của mình để hạn chế việc sử dụng chúng cho các ứng dụng khách đã đăng ký, đã biết. Trong trường hợp này, bạn có thể sử dụngBasiclược đồ xác thực với mã định danh máy khách là id người dùng và bí mật được chia sẻ máy khách làm mật khẩu. Bạn không cần các chương trình xác thực độc quyền chỉ cần xác định rõ ràng (các) một (các) ứng dụng khách sẽ sử dụng cho mỗi không gian bảo vệ. Tôi chỉ thích một cho mỗi không gian bảo vệ nhưng các tiêu chuẩn HTTP cho phép cả nhiều sơ đồ xác thực trên mỗi phản hồi tiêu đề WWW-Authenticate và nhiều tiêu đề WWW-Authenticate trong mỗi phản hồi; điều này sẽ gây nhầm lẫn cho các ứng dụng API nên sử dụng các tùy chọn nào. Hãy nhất quán và rõ ràng thì các API của bạn sẽ được sử dụng.

— Steve Dearborn
nguồn
2

Tôi khuyên bạn không nên sử dụng xác thực HTTP với tên lược đồ tùy chỉnh. Tuy nhiên, nếu bạn cảm thấy rằng bạn có thứ gì đó sử dụng chung, bạn có thể xác định một lược đồ mới. Xem http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 để biết chi tiết.

— Julian Reschke
nguồn
Tài liệu để liên kết đến là bản nháp của HTTP / 1.1. Tôi đã cố gắng xem xét tiêu chuẩn cuối cùng và không thể tìm thấy bất cứ điều gì về việc tôi phải đăng ký các chương trình tùy chỉnh. Điều này có thể không chỉ là, trong quá trình soạn thảo, họ muốn tìm và đồng ý về các đề án mặc định?
— Thomas Watson
Thomas, tài liệu tôi đã tham khảo là bản sửa đổi của RFCs 2616/7 (không có đăng ký cho các lược đồ). Công việc đang được tiến hành nhưng sắp hoàn thành.
— Julian Reschke
1

Vui lòng thử bên dưới trên người đưa thư: -

Trong phần tiêu đề, ví dụ làm việc cho tôi ..

Ủy quyền: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU

— Madan Dale
nguồn
1
Bạn có thực sự gửi mật khẩu / băm trong JWT không? Nó là một base64 đơn giản.
— Zakhar
1
@Zakhar: thực tiễn khá điển hình đối với các SPA là đóng gói toàn bộ phiên người dùng trong JWT (vì nó là một tài liệu json hoàn chỉnh), loại bỏ nhu cầu lưu trữ phiên ở phía máy chủ.
— cowbert
@cowbert: Tôi không chắc liệu có phải thông thường để đóng gói một cái gì đó nhiều hơn một loại mã thông báo phiên trong JWT hay không (xem ví dụ bài đăng này ).
— Alexander Abakumov
1
@AlexanderAbakumov rằng bài báo đầy sự hiểu lầm, anh ấy có một số điểm, nhưng rất nhiều điểm của anh ấy không có ý nghĩa và một số sau đó anh ấy chỉ chống lại mà không có lý do gì, tôi có thể nói rằng anh ấy chỉ thích bánh quy và tôi nghĩ anh ấy cần nhận được một số từ Bakery và sửa bài viết của anh ấy, tôi gặp rất nhiều tình huống tôi sử dụng cookie và lãng phí ngày làm việc, JWT với localStorage đã giúp tôi rất đau đầu và thời gian, chỉ là 2 tiếng làm việc và nổ, không bao giờ ghé thăm nó nữa. Tôi tự hỏi liệu anh ấy đã bao giờ phát triển một ứng dụng di động, thử các trình duyệt với các quy tắc bảo mật bị hạn chế chặt chẽ, v.v.
— Al-Mothafar
@ Al-Mothafar: Tôi đánh giá cao nếu bạn mở rộng trên báo cáo của bạn như that article full of misleadings, a lot of his points does not make sensevv một cách nào đó (có nghĩa là, nó có thể là một cái gì đó vượt quá một bình luận ở đây). Có lẽ bạn có thể viết một câu trả lời hoặc một bài đăng trên blog? Sẽ thực sự thú vị nếu so sánh các lập luận.
— Alexander Abakumov
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.