Tôi đang làm việc để triển khai OAuth 2.0 JWT access_token trong máy chủ xác thực của mình. Tuy nhiên, tôi không rõ sự khác biệt giữa audxác nhận quyền sở hữu JWT và client_idgiá trị tiêu đề HTTP. Chúng có giống nhau không? Nếu không, bạn có thể giải thích sự khác biệt giữa hai?

Sự nghi ngờ của tôi là điều đó audnên tham chiếu đến (các) máy chủ tài nguyên và client_idphải tham chiếu đến một trong các ứng dụng khách được máy chủ xác thực công nhận (tức là ứng dụng web hoặc ứng dụng iOS).

Trong trường hợp hiện tại của tôi, máy chủ tài nguyên của tôi cũng là ứng dụng khách web của tôi.

Hóa ra, những nghi ngờ của tôi đã đúng. audYêu cầu đối tượng trong JWT có nghĩa là đề cập đến Máy chủ tài nguyên sẽ chấp nhận mã thông báo.

Như bài đăng này chỉ đơn giản là:

Đối tượng của mã thông báo là người nhận mã thông báo dự kiến.

Giá trị đối tượng là một chuỗi - thường là địa chỉ cơ sở của tài nguyên đang được truy cập, chẳng hạn như https://contoso.com.

Trong client_idOAuth đề cập đến ứng dụng khách sẽ yêu cầu tài nguyên từ Máy chủ tài nguyên.

Ứng dụng Khách (ví dụ: ứng dụng iOS của bạn) sẽ yêu cầu JWT từ Máy chủ xác thực của bạn. Khi làm như vậy, nó sẽ chuyển nó client_idvà client_secretcùng với bất kỳ thông tin đăng nhập nào của người dùng có thể được yêu cầu. Máy chủ ủy quyền xác thực máy khách bằng cách sử dụng client_idvàclient_secret và trả về JWT.

JWT sẽ chứa một audxác nhận quyền sở hữu chỉ định Máy chủ tài nguyên mà JWT hợp lệ. Nếu audchứa www.myfunwebapp.com, nhưng ứng dụng khách cố gắng sử dụng JWT trên www.supersecretwebapp.com, thì quyền truy cập sẽ bị từ chối vì Máy chủ tài nguyên đó sẽ thấy rằng JWT không dành cho nó.

audTuyên bố JWT (Đối tượng)

Theo RFC 7519 :

Yêu cầu "aud" (đối tượng) xác định những người nhận mà JWT dành cho. Mỗi hiệu trưởng dự định xử lý JWT PHẢI tự xác định mình với một giá trị trong yêu cầu của khán giả. Nếu bên xử lý chính xác nhận quyền sở hữu không tự xác định giá trị trong xác nhận quyền sở hữu "kiểm toán" khi xác nhận quyền sở hữu này có mặt, thì JWT PHẢI bị từ chối. Trong trường hợp chung, giá trị "aud" là một mảng các chuỗi phân biệt chữ hoa chữ thường, mỗi chuỗi chứa một giá trị StringOrURI. Trong trường hợp đặc biệt khi JWT có một đối tượng, giá trị "aud" CÓ THỂ là một chuỗi phân biệt chữ hoa chữ thường duy nhất chứa giá trị StringOrURI. Việc giải thích các giá trị đối tượng nói chung là ứng dụng cụ thể. Việc sử dụng xác nhận quyền sở hữu này là TÙY CHỌN.

Yêu cầu đối tượng ( aud) như được xác định bởi thông số kỹ thuật là chung và là ứng dụng cụ thể. Mục đích sử dụng là để xác định những người nhận dự định của mã thông báo. Ý nghĩa của người nhận là ứng dụng cụ thể. Giá trị đối tượng là một danh sách các chuỗi hoặc có thể là một chuỗi đơn nếu chỉ có một audxác nhận quyền sở hữu. Người tạo mã thông báo không thực thi điều đó đã audđược xác thực chính xác, trách nhiệm là của người nhận để xác định xem mã thông báo có nên được sử dụng hay không.

Dù giá trị là gì, khi người nhận xác thực JWT và nó muốn xác thực rằng mã thông báo được dự định sử dụng cho các mục đích của nó, nó PHẢI xác định giá trị nào trong audnhận dạng chính nó và mã thông báo chỉ nên xác thực nếu ID được khai báo của người nhận là trình bày trong audyêu cầu. Nó không quan trọng nếu đây là một URL hoặc một số chuỗi ứng dụng cụ thể khác. Ví dụ: nếu hệ thống của tôi quyết định tự nhận dạng audbằng chuỗi: api3.app.comthì nó sẽ chỉ chấp nhận JWT nếu audxác nhận quyền sở hữu chứa api3.app.comtrong danh sách các giá trị đối tượng của nó.

Tất nhiên người nhận có thể chọn bỏ qua aud, vì vậy điều này chỉ hữu ích nếu người nhận muốn xác thực tích cực rằng mã thông báo được tạo riêng cho nó.

Giải thích của tôi dựa trên đặc điểm kỹ thuật là audxác nhận quyền sở hữu hữu ích để tạo JWT được xây dựng theo mục đích chỉ hợp lệ cho các mục đích nhất định. Đối với một hệ thống, điều này có nghĩa là bạn muốn một mã thông báo hợp lệ cho một số tính năng, nhưng không hợp lệ cho một số tính năng khác. Bạn có thể phát hành mã thông báo chỉ được giới hạn cho một "đối tượng" nhất định, trong khi vẫn sử dụng cùng một khóa và thuật toán xác thực.

Vì trong trường hợp điển hình, JWT được tạo bởi một dịch vụ đáng tin cậy và được sử dụng bởi các hệ thống đáng tin cậy khác (hệ thống không muốn sử dụng mã thông báo không hợp lệ), các hệ thống này chỉ cần phối hợp các giá trị mà chúng sẽ sử dụng.

Tất nhiên, audlà hoàn toàn tùy chọn và có thể bỏ qua nếu trường hợp sử dụng của bạn không đảm bảo. Nếu bạn không muốn hạn chế các mã thông báo được sử dụng bởi các đối tượng cụ thể hoặc không có hệ thống nào trong số các hệ thống của bạn thực sự xác nhận audmã thông báo, thì điều đó là vô ích.

Ví dụ: Mã thông báo truy cập và làm mới

Một ví dụ tiếp theo (nhưng đơn giản) mà tôi có thể nghĩ đến là có lẽ chúng tôi muốn sử dụng JWT để truy cập và làm mới mã thông báo mà không cần phải triển khai các thuật toán và khóa mã hóa riêng biệt, nhưng chỉ muốn đảm bảo rằng mã thông báo truy cập sẽ không xác thực dưới dạng mã làm mới hoặc ngược lại -sao.

Bằng cách sử dụng, audchúng tôi có thể chỉ định yêu cầu về refreshmã thông báo làm mới và yêu cầu về accessmã thông báo truy cập khi tạo các mã thông báo này. Khi có yêu cầu nhận mã truy cập mới từ mã làm mới, chúng tôi cần xác thực rằng mã làm mới đó là mã làm mới chính hãng. Việc audxác thực như được mô tả ở trên sẽ cho chúng tôi biết liệu mã thông báo có thực sự là một mã thông báo làm mới hợp lệ hay không bằng cách xem xét cụ thể yêu cầu của refreshtrong aud.

ID ứng dụng khách OAuth so với audXác nhận quyền sở hữu JWT

ID ứng dụng khách OAuth hoàn toàn không liên quan và không có mối tương quan trực tiếp với các audxác nhận quyền sở hữu JWT . Theo quan điểm của OAuth, các mã thông báo là các vật thể không trong suốt.

Ứng dụng chấp nhận các mã thông báo này có trách nhiệm phân tích cú pháp và xác thực ý nghĩa của các mã thông báo này. Tôi không thấy nhiều giá trị trong việc chỉ định ID ứng dụng khách OAuth trong audxác nhận quyền sở hữu JWT .

Nếu bạn đến đây để tìm kiếm OpenID Connect (OIDC): OAuth 2.0! = OIDC

Tôi nhận ra rằng điều này được gắn thẻ cho oauth 2.0 và KHÔNG phải OIDC, tuy nhiên, thường có sự nhầm lẫn giữa hai tiêu chuẩn vì cả hai tiêu chuẩn đều có thể sử dụng JWT và audxác nhận quyền sở hữu. Và một (OIDC) về cơ bản là một phần mở rộng của cái kia (OAUTH 2.0). (Tôi tình cờ gặp câu hỏi này khi tự tìm OIDC.)

Mã thông báo truy cập OAuth 2.0 ##

Đối với mã thông báo Truy cập OAuth 2.0 , các câu trả lời hiện có bao gồm khá tốt. Ngoài ra, đây là một phần có liên quan từ Khung OAuth 2.0 (RFC 6749)

Đối với các ứng dụng khách công cộng sử dụng các luồng ngầm định, đặc tả này không cung cấp bất kỳ phương pháp nào để ứng dụng xác định mã thông báo truy cập đã được cấp cho khách hàng nào.
... Việc
xác thực chủ sở hữu tài nguyên cho khách hàng nằm ngoài phạm vi của đặc tả này. Bất kỳ thông số kỹ thuật nào sử dụng quy trình ủy quyền như một hình thức xác thực người dùng cuối được ủy quyền cho ứng dụng khách (ví dụ: dịch vụ đăng nhập của bên thứ ba) KHÔNG ĐƯỢC sử dụng quy trình ngầm định mà không có cơ chế bảo mật bổ sung cho phép khách hàng xác định xem quyền truy cập mã thông báo đã được phát hành để sử dụng (ví dụ: đối tượng hạn chế mã thông báo truy cập).

Mã thông báo ID OIDC ##

OIDC có Mã thông báo ID ngoài Mã thông báo truy cập. Thông số OIDC rõ ràng về việc sử dụng audyêu cầu trong Mã thông báo ID. ( openid-connect-core-1.0 )

kiểm toán
BẮT BUỘC. (Các) đối tượng mà Mã thông báo ID này dành cho. Nó PHẢI chứa client_id OAuth 2.0 của Relying Party dưới dạng giá trị đối tượng. Nó cũng CÓ THỂ chứa các số nhận dạng cho các đối tượng khác. Trong trường hợp chung, giá trị aud là một mảng các chuỗi phân biệt chữ hoa chữ thường. Trong trường hợp đặc biệt phổ biến khi có một đối tượng, giá trị kiểm âm CÓ THỂ là một chuỗi phân biệt chữ hoa chữ thường.

hơn nữa OIDC chỉ định xác azpnhận quyền sở hữu được sử dụng cùng với audkhi audcó nhiều hơn một giá trị.

azp
TÙY CHỌN. Bên được ủy quyền - bên mà Mã ID được cấp. Nếu có, nó PHẢI chứa ID ứng dụng khách OAuth 2.0 của bên này. Xác nhận quyền sở hữu này chỉ cần thiết khi Mã thông báo ID có một giá trị đối tượng duy nhất và đối tượng đó khác với bên được ủy quyền. Nó CÓ THỂ được đưa vào ngay cả khi bên được ủy quyền giống với đối tượng duy nhất. Giá trị azp là một chuỗi phân biệt chữ hoa chữ thường chứa giá trị StringOrURI.

Mặc dù điều này đã cũ, nhưng tôi nghĩ câu hỏi vẫn còn giá trị cho đến ngày nay

Tôi nghi ngờ là aud nên tham chiếu đến (các) máy chủ tài nguyên và client_id nên tham chiếu đến một trong các ứng dụng khách được máy chủ xác thực công nhận

Vâng, aud nên tham khảo vào mã thông báo bên tiêu thụ. Và client_id đề cập đến bên nhận mã thông báo.

Trong trường hợp hiện tại của tôi, máy chủ tài nguyên của tôi cũng là ứng dụng khách web của tôi.

Trong kịch bản của OP, ứng dụng web và máy chủ tài nguyên đều thuộc cùng một bên. Vì vậy, điều này có nghĩa là khách hàng và khán giả giống nhau. Nhưng có thể có những trường hợp không đúng như vậy.

Hãy nghĩ về một SPA sử dụng tài nguyên được bảo vệ bằng OAuth. Trong trường hợp này, SPA là khách hàng. Tài nguyên được bảo vệ là đối tượng của mã thông báo truy cập.

Kịch bản thứ hai này thật thú vị. Có một bản nháp đang hoạt động có tên " Chỉ báo tài nguyên cho OAuth 2.0 " giải thích nơi bạn có thể xác định đối tượng dự kiến ​​trong yêu cầu ủy quyền của mình. Vì vậy, mã thông báo kết quả sẽ bị hạn chế đối tượng được chỉ định. Ngoài ra, Azure OIDC sử dụng một cách tiếp cận tương tự, trong đó nó cho phép đăng ký tài nguyên và cho phép yêu cầu xác thực chứa tham số tài nguyên để xác định đối tượng dự kiến ​​của mã thông báo truy cập. Các cơ chế như vậy cho phép các vị trí quảng cáo OAuth có sự tách biệt giữa khách hàng và bên tiêu thụ mã thông báo (đối tượng).