Sự nhầm lẫn loại phản hồi OpenIDConnect

Question

Tôi đã dành vài ngày qua để đọc qua tất cả các thông số kỹ thuật liên quan đến OAuth2 và OpenIDConnect và triển khai ứng dụng khách thử nghiệm bằng cách sử dụng Máy chủ nhận dạng Thinktecture. Tôi cũng đã theo một số khóa học đa dạng và tôi nghĩ rằng hiểu được ý chính của nó. Tuy nhiên tôi vẫn còn rất bối rối về các loại trả lời.

Thông số OpenIDConnect chỉ định rằng loại phản hồi luồng hỗn hợp là kết hợp của "mã", "id_token" và "mã thông báo". Tôi hiểu "id_token" cho phép chúng ta truy cập vào thông tin id cơ bản ban đầu. Tôi cũng hiểu mã "đề cập đến mã ủy quyền và" mã thông báo "đề cập đến mã thông báo truy cập và kết hợp" mã "với một hoặc cả hai mã khác kích hoạt luồng nhưng hiểu biết của tôi là bạn trao đổi mã ủy quyền cho một thẻ truy cập trong dòng chảy Authorization, trong khi dòng chảy ngầm cung cấp cho mã truy cập ngầm?

có thể ai đó làm sáng tỏ sự nhầm lẫn của tôi?

Answer 1

Các câu sau đây mà bạn đã thực hiện là chính xác:

• code đề cập đến Authorization Mã
• token đề cập đến một access token hoặc (access_token)
• trong Bộ Luật Cho Phép chảy một chuyển mạch code cho một số access_token

Nhưng một phần của con hợp nhất có thể bắt nguồn từ hỗn hợp thuật ngữ:

• thuật ngữ Luồng ủy quyền không hoàn toàn chính xác; Tên chính thức của nó là Authorization Mã chảy
• Access Mã hạn không tồn tại
• dòng chảy ngầm định không có một Mã ủy quyền (và cũng không Mã số truy cập) trên thực tế không có chứng chỉ (hoặc cấp) tham gia vào tất cả những gì cho phép Client để có được thẻ từ thiết bị đầu cuối token, do đó nó là tên

Như @juanifioren chỉ ra, dòng hybrid kết hợp điều:

• dòng chảy code id_token sẽ nhận được một code và id_token trong đáp ứng xác thực trực tiếp nhưng bạn muốn sử dụng code để có được một access_token từ endpoint Mã
• dòng chảy code token sẽ nhận được một code và access_token trong đáp ứng xác thực trực tiếp nhưng bạn muốn sử dụng để có được một codeid_token và có thể khác access_token trong backend từ endpoint Mã
• dòng chảy code id_token token sẽ nhận được một code, access_token và một id_token trong đáp ứng xác thực trực tiếp và bạn có thể sử dụng code trong backend để có được khácaccess_token từ endpoint Mã

Bắt một access_token từ endpoint Mã khác với nhận nó từ thiết bị đầu cuối Authorization vì khách hàng bí mật tự xác thực với thiết bị đầu cuối Mã (chứ không phải Điểm cuối ủy quyền). Do đó, access_token cho phần bí mật của khách hàng có thể có nhiều quyền hơn và tuổi thọ dài hơn.

Xem thêm một sợi ngắn trên mailing list đặc tả về chủ đề này: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150209/005229.html

Answer 2

những suy nghĩ của bạn về Authorization Mã Flow và dòng chảy ngầm là đúng. Nhưng tôi nghĩ rằng bạn Khi sử dụng lai bạn chỉ đơn giản là có thể nhận cả mã và id_token.

Sau đó, bạn có thể lấy mã và trao đổi mã cho mã thông báo truy cập hoặc chỉ sử dụng mã nhận dạng id_token (hoặc mã thông báo truy cập) trực tiếp. Cả hai phương pháp đều có sai sót riêng của họ, đặc biệt là về an ninh.

Answer 3

Để hiểu được các mối quan hệ có thể có giữa các loại đáp ứng và Grant loại thấy IdentityServer4\Constants.cs

public static readonly Dictionary<string, string> ResponseTypeToGrantTypeMapping = new Dictionary<string, string> 
     { 
      { OidcConstants.ResponseTypes.Code, GrantType.AuthorizationCode }, 
      { OidcConstants.ResponseTypes.Token, GrantType.Implicit }, 
      { OidcConstants.ResponseTypes.IdToken, GrantType.Implicit }, 
      { OidcConstants.ResponseTypes.IdTokenToken, GrantType.Implicit }, 
      { OidcConstants.ResponseTypes.CodeIdToken, GrantType.Hybrid }, 
      { OidcConstants.ResponseTypes.CodeToken, GrantType.Hybrid }, 
      { OidcConstants.ResponseTypes.CodeIdTokenToken, GrantType.Hybrid } 
     };