Mã thông báo mang OAuth 2.0 chính xác là gì?

Theo RFC6750 -Khung ủy quyền OAuth 2.0: Sử dụng mã thông báo mang, mã thông báo mang là:

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ể.

Đối với tôi định nghĩa này là mơ hồ và tôi không thể tìm thấy bất kỳ đặc điểm kỹ thuật.

• Giả sử tôi đang triển khai một nhà cung cấp ủy quyền, tôi có thể cung cấp bất kỳ loại chuỗi nào cho mã thông báo không?
• Nó có thể là một chuỗi ngẫu nhiên?
• Nó có phải là mã hóa base64 của một số thuộc tính không?
  Có nên băm?
• Và nhà cung cấp dịch vụ có cần truy vấn nhà cung cấp ủy quyền để xác thực mã thông báo này không?

Cảm ơn bạn cho bất kỳ con trỏ.

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. 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).

Mã thông báo Bearer được tạo cho bạn bởi máy chủ Xác thực. Khi người dùng xác thực ứng dụng của bạn (máy khách), máy chủ xác thực sẽ đi và tạo cho bạn một Mã thông báo. Mã thông báo mang là loại mã thông báo truy cập chiếm ưu thế được sử dụng với OAuth 2.0. Về cơ bản, mã thông báo Bearer nói "Cung cấp cho người mang quyền truy cập mã thông báo này".

Mã thông báo Bearer thường là một loại giá trị mờ được tạo bởi máy chủ xác thực. Nó không phải là ngẫu nhiên; nó được tạo dựa trên người dùng cấp cho bạn quyền truy cập và ứng dụng khách của bạn có quyền truy cập.

Để truy cập API chẳng hạn, bạn cần sử dụng Mã thông báo truy cập. Mã thông báo truy cập được tồn tại trong thời gian ngắn (khoảng một giờ). Bạn sử dụng mã thông báo mang để nhận mã thông báo Access mới. Để nhận mã thông báo truy cập, bạn gửi máy chủ Xác thực mã thông báo mang này cùng với id khách hàng của bạn. Bằng cách này, máy chủ biết rằng ứng dụng sử dụng mã thông báo mang là chính ứng dụng mà mã thông báo mang đã được tạo cho. Ví dụ: Tôi không thể lấy mã thông báo được tạo cho ứng dụng của bạn và sử dụng nó với ứng dụng của tôi, nó sẽ không hoạt động vì nó không được tạo cho tôi.

Mã thông báo Google Làm mới trông giống như thế này: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

được sao chép từ nhận xét: Tôi không nghĩ rằng có bất kỳ hạn chế nào đối với mã thông báo mang bạn cung cấp. Điều duy nhất tôi có thể nghĩ là thật tuyệt khi cho phép nhiều hơn một. Ví dụ: người dùng có thể xác thực ứng dụng tối đa 30 lần và mã thông báo mang cũ vẫn sẽ hoạt động. oh và nếu một người đã không được sử dụng trong 6 tháng, tôi sẽ xóa nó khỏi hệ thống của bạn. Đó là máy chủ xác thực của bạn sẽ phải tạo ra chúng và xác thực chúng, vì vậy nó được định dạng như thế nào là tùy thuộc vào bạn.

Cập nhật:

Mã thông báo Bearer được đặt trong tiêu đề Ủy quyền của mọi Yêu cầu HTTP hành động nội tuyến. Ví dụ:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

Chuỗi "AbCdEf123456"trong ví dụ trên là mã thông báo ủy quyền không ghi tên. Đây là mã thông báo mã hóa được tạo bởi máy chủ xác thực. Tất cả các mã thông báo mang được gửi với các hành động đều có trường sự cố, với trường đối tượng chỉ định miền người gửi dưới dạng URL có dạng https: //. Ví dụ: nếu email đến từ noreply@example.com, thì đối tượng là https://example.com .

Nếu sử dụng mã thông báo mang, hãy xác minh rằng yêu cầu đến từ máy chủ xác thực và được dành cho miền người gửi. Nếu mã thông báo không xác minh, dịch vụ sẽ đáp ứng yêu cầu với mã phản hồi HTTP 401 (Không được phép).

Mã thông báo mang là một phần của tiêu chuẩn OAuth V2 và được nhiều API áp dụng rộng rãi.

Khi tôi đọc câu hỏi của bạn, tôi đã thử mà không thành công khi tìm kiếm trên Internet cách mã thông báo Bearer được mã hóa hoặc ký tên. Tôi đoán mã thông báo mang không được băm (có thể một phần, nhưng không hoàn toàn) bởi vì trong trường hợp đó, sẽ không thể giải mã nó và lấy các thuộc tính của người dùng từ nó.

Nhưng câu hỏi của bạn dường như đang cố gắng tìm câu trả lời về chức năng mã thông báo Bearer:

Giả sử tôi đang triển khai một nhà cung cấp ủy quyền, tôi có thể cung cấp bất kỳ loại chuỗi nào cho mã thông báo không? Nó có thể là một chuỗi ngẫu nhiên? Nó có phải là mã hóa base64 của một số thuộc tính không? Có nên băm?

Vì vậy, tôi sẽ cố gắng giải thích cách hoạt động của mã thông báo Bearer và Làm mới mã thông báo:

Khi người dùng yêu cầu máy chủ gửi mã thông báo gửi mật khẩu và người dùng thông qua SSL, máy chủ sẽ trả về hai thứ: mã thông báo truy cập và mã thông báo làm mới .

Mã thông báo truy cập là mã thông báo Bearer mà bạn sẽ phải thêm vào tất cả các tiêu đề yêu cầu để được xác thực là người dùng cụ thể.

Authorization: Bearer <access_token>

Mã thông báo truy cập là một chuỗi được mã hóa với tất cả các thuộc tính, Khiếu nại và Vai trò người dùng mà bạn muốn. (Bạn có thể kiểm tra kích thước của mã thông báo tăng nếu bạn thêm nhiều vai trò hoặc khiếu nại hơn). Khi Máy chủ tài nguyên nhận được mã thông báo truy cập, nó sẽ có thể giải mã nó và đọc các thuộc tính người dùng này. Bằng cách này, người dùng sẽ được xác nhận và cấp cùng với tất cả các ứng dụng.

Mã thông báo truy cập có thời gian hết hạn ngắn (ví dụ: 30 phút). Nếu mã thông báo truy cập đã hết hạn lâu thì đó sẽ là một vấn đề, vì về mặt lý thuyết không có khả năng thu hồi nó. Vì vậy, hãy tưởng tượng một người dùng có vai trò = "Quản trị viên" thay đổi thành "Người dùng". Nếu người dùng giữ mã thông báo cũ với vai trò = "Quản trị viên", anh ta sẽ có thể truy cập cho đến khi hết hạn mã thông báo với quyền Quản trị viên. Đó là lý do tại sao mã thông báo truy cập hết hạn ngắn.

Nhưng, một vấn đề xuất hiện trong tâm trí. Nếu mã thông báo truy cập hết hạn ngắn, chúng tôi phải gửi cho mỗi người dùng và mật khẩu trong một khoảng thời gian ngắn. Điều này có an toàn không? Không, không phải vậy. Chúng ta nên tránh nó. Đó là khi mã thông báo Làm mới xuất hiện để giải quyết vấn đề này.

Mã thông báo làm mới được lưu trữ trong DB và sẽ hết hạn lâu (ví dụ: 1 tháng).

Người dùng có thể nhận được mã thông báo Access mới (khi hết hạn, cứ sau 30 phút) bằng cách sử dụng mã thông báo làm mới, mà người dùng đã nhận được trong yêu cầu đầu tiên về mã thông báo. Khi mã thông báo truy cập hết hạn, khách hàng phải gửi mã thông báo làm mới. Nếu mã thông báo làm mới này tồn tại trong DB, máy chủ sẽ trả về cho khách hàng mã thông báo truy cập mới và mã thông báo làm mới khác (và sẽ thay thế mã thông báo làm mới cũ bằng mã thông báo mới).

Trong trường hợp mã thông báo truy cập của người dùng đã bị xâm phạm, mã thông báo làm mới của người dùng đó phải bị xóa khỏi DB. Bằng cách này, mã thông báo sẽ chỉ có hiệu lực cho đến khi mã thông báo truy cập hết hạn vì khi tin tặc cố gắng nhận mã thông báo truy cập mới gửi mã thông báo làm mới, hành động này sẽ bị từ chối.

Mã thông báo mang là một hoặc nhiều lần lặp lại của bảng chữ cái, chữ số, "-", "." , "_", "~", "+", "/" theo sau là 0 hoặc nhiều hơn "=".

RFC 6750 2.1. Trường tiêu đề yêu cầu ủy quyền (Định dạng là ABNF (BNF tăng cường))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Nó trông giống Base64 nhưng theo mã thông báo trong tiêu đề có nên được mã hóa Base64 không? , không phải vậy.

Tìm hiểu sâu hơn một chút về "HTTP / 1.1, phần 7: Xác thực" **, tuy nhiên, tôi thấy rằng b64token chỉ là một định nghĩa cú pháp ABNF cho phép các ký tự thường được sử dụng trong base64, base64url, v.v. Vì vậy, b64token không xác định bất kỳ mã hóa hoặc giải mã nào, nhưng chỉ xác định những ký tự nào có thể được sử dụng trong phần tiêu đề ủy quyền sẽ chứa mã thông báo truy cập.

Người giới thiệu

• RFC 5234 3.6. Biến lặp lại: * Quy tắc
• RFC 2616 2.1 BNF tăng cường