Loại tiêu đề ủy quyền HTTP tốt nhất cho JWT

Tôi đang tự hỏi Authorizationloại tiêu đề HTTP thích hợp nhất cho mã thông báo JWT là gì .

Một trong những loại có lẽ phổ biến nhất là Basic. Ví dụ:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Nó xử lý hai tham số như đăng nhập và mật khẩu. Vì vậy, nó không liên quan đến mã thông báo JWT.

Ngoài ra, tôi đã nghe về loại Bearer , ví dụ:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Tuy nhiên, tôi không biết ý nghĩa của nó. Có liên quan đến gấu?

Có cách nào đặc biệt để sử dụng mã thông báo JWT trong Authorizationtiêu đề HTTP không? Chúng ta nên sử dụng Bearer, hay chúng ta nên đơn giản hóa và chỉ sử dụng:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Cảm ơn.

Biên tập:

Hoặc có thể, chỉ là một JWTtiêu đề HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Tiêu đề HTTP tốt nhất để khách hàng của bạn gửi mã thông báo truy cập (JWT hoặc bất kỳ mã thông báo nào khác) là Authorizationtiêu đề có Bearersơ đồ xác thực.

Sơ đồ này được mô tả bởi RFC6750 .

Thí dụ:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

Nếu bạn cần bảo vệ an ninh mạnh mẽ hơn, bạn cũng có thể xem xét dự thảo IETF sau: https://tools.ietf.org/html/draft-ietf-oauth-pop-arch architecture . Dự thảo này dường như là một thay thế tốt cho (bị bỏ rơi?) Https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac .

Lưu ý rằng ngay cả khi RFC này và các thông số kỹ thuật trên có liên quan đến giao thức OAuth2 Framework, chúng có thể được sử dụng trong bất kỳ bối cảnh nào khác yêu cầu trao đổi mã thông báo giữa máy khách và máy chủ.

Không giống như JWTlược đồ tùy chỉnh mà bạn đề cập trong câu hỏi của bạn, chương trình Bearerđược đăng ký tại IANA .

Liên quan đến các lược đồ Basicvà Digestxác thực, chúng được dành riêng để xác thực bằng tên người dùng và bí mật (xem RFC7616 và RFC7617 ) để không áp dụng trong ngữ cảnh đó.

Câu trả lời ngắn

Các Bearercơ chế thẩm định là những gì bạn đang tìm kiếm.

Câu trả lời dài

Có liên quan đến gấu?

Ơ ... Không :)

Theo Từ điển Oxford , đây là định nghĩa của người mang :

người mang _{^{/ bɛːrə /}}
danh từ

1. Một người hoặc vật mang hoặc giữ một cái gì đó.

2. Một người xuất trình séc hoặc lệnh khác để trả tiền.

Định nghĩa đầu tiên bao gồm các từ đồng nghĩa sau: messenger , đại lý , băng tải , sứ giả , người vận chuyển , nhà cung cấp .

Và đây là định nghĩa về mã thông báo mang theo RFC 6750 :

1.2. Thuật ngữ

Mã thông báo mang

Mã thông báo bảo mật với tài sản mà bất kỳ bên nào sở hữu mã thông báo ("người mang") có thể sử dụng mã thông báo theo bất kỳ cách nào mà bất kỳ bên nào khác sở hữu có thể. Sử dụng mã thông báo mang không yêu cầu người mang chứng minh sở hữu tài liệu khóa mật mã (bằng chứng sở hữu).

Các Bearerchương trình xác thực được đăng ký tại IANA và ban đầu được định nghĩa trong RFC 6750 cho các khuôn khổ cho phép OAuth 2.0, nhưng không dừng lại bạn bằng cách sử dụng Bearerchương trình cho thẻ truy cập trong các ứng dụng không sử dụng OAuth 2.0.

Bám sát các tiêu chuẩn càng nhiều càng tốt và đừng tạo các sơ đồ xác thực của riêng bạn.

Mã thông báo truy cập phải được gửi trong Authorizationtiêu đề yêu cầu bằng cách sử dụng Bearerlược đồ xác thực:

2.1. Trường tiêu đề yêu cầu ủy quyền

Khi gửi mã thông báo truy cập trong trường Authorizationtiêu đề yêu cầu được xác định bởi HTTP / 1.1, khách hàng sử dụng Bearersơ đồ xác thực để truyền mã thông báo truy cập.

Ví dụ:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

Khách hàng NÊN thực hiện các yêu cầu được xác thực bằng mã thông báo mang theo sử dụng trường Authorizationtiêu đề yêu cầu với Bearersơ đồ ủy quyền HTTP. [...]

Trong trường hợp mã thông báo không hợp lệ hoặc bị thiếu, Bearerlược đồ nên được bao gồm trong WWW-Authenticatetiêu đề phản hồi:

3. Trường tiêu đề phản hồi xác thực WWW

Nếu yêu cầu tài nguyên được bảo vệ không bao gồm thông tin xác thực hoặc không chứa mã thông báo truy cập cho phép truy cập vào tài nguyên được bảo vệ, máy chủ tài nguyên PHẢI bao gồm trường WWW-Authenticatetiêu đề phản hồi HTTP [...].

Tất cả các thách thức được xác định bởi thông số kỹ thuật này PHẢI sử dụng giá trị auth -eme Bearer. Lược đồ này PHẢI được theo sau bởi một hoặc nhiều giá trị auth-param. [...].

Ví dụ: để đáp ứng yêu cầu tài nguyên được bảo vệ mà không cần xác thực:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

Và để đáp ứng yêu cầu tài nguyên được bảo vệ với nỗ lực xác thực bằng cách sử dụng mã thông báo truy cập đã hết hạn:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"