web-dev-qa-db-ja.com

OpenIDConnect応答タイプの混乱

ここ数日、OAuth2とOpenIDConnectに関するすべての仕様を読み、Thinktecture IdentityServerを使用してテストクライアントを実装しました。また、複数のサイトのコースをいくつか受講しましたが、その主な要点を理解していると思います。しかし、私はまだ応答タイプについて非常に混乱しています。

OpenIDConnect仕様では、ハイブリッドフロー応答タイプが「コード」、「id_token」、および「トークン」の組み合わせであると指定されています。 「id_token」を使用すると、最初に基本的なID情報にアクセスできることを理解しています。

「コード」は認証コードを指し、「トークン」はアクセストークンを指し、「コード」を他の2つのトリガーの一方または両方と組み合わせるとフローがトリガーされることも理解していますが、認証コードをアクセストークンと交換することは承認フロー、暗黙フローはアクセスコードを暗黙的に提供しますか？

誰かが私の混乱を解消できますか？

asp.netasp.net-web-apioauth-2.0openid-connect
12
RNDThoughts

あなたが行った次のステートメントは正しいです：

  • codeは認証コードを指します
  • tokenはアクセストークンまたは（access_token）を指します
  • 認証コードフローでは、codeをaccess_tokenに切り替えます。

しかし、混乱の一部は、用語の取り違えに起因している可能性があります。

  • 承認フローという用語は完全には正しくありません。その正式名称は認証コードフローです
  • アクセスコードという用語は存在しません
  • 暗黙的なフローには認証コード（またはアクセスコード）がありません。実際、クライアントがトークンエンドポイントからトークンを取得できるようにする資格情報（または付与）はまったく含まれていません。したがって、それは名前です

@juanifiorenが指摘したように、ハイブリッドフローは次のことを組み合わせています。

  • code id_tokenフローは認証応答でcodeとid_tokenを直接取得しますが、トークンからaccess_tokenを取得するにはcodeを使用します終点
  • code tokenフローは認証応答でcodeとaccess_tokenを直接取得しますが、codeを使用してid_tokenとおそらく別のトークンエンドポイントからのバックエンドのaccess_token
  • code id_token tokenフローは、認証応答でcode、access_token、およびid_tokenを直接およびバックエンドでcodeを使用して、トークンエンドポイントからanotheraccess_tokenを取得できます

トークンエンドポイントからaccess_tokenを取得することは、認証エンドポイントから取得することとは異なります。これは、機密クライアントが（認証エンドポイントではなく）トークンエンドポイントに対して自身を認証するためです。したがって、クライアントの機密部分のaccess_tokenは、より多くのアクセス許可またはより長い寿命を持つ可能性があります。

このトピックに関するスペックメーリングリストの短いスレッドも参照してください： http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150209/005229.html

17
Hans Z.

応答タイプと付与タイプの間の可能な関係を理解するには、 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 }
        };
8
Michael Freidgeim

https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660#9401

6。 response_type =コードトークン

Response_typeの値がcodetokenの場合、認証コードとアクセストークンが認証エンドポイントから発行され、アクセストークンがトークンエンドポイントから発行されます。また、スコープリクエストパラメータにopenidが含まれている場合は、トークンエンドポイントからもIDトークンが発行されます。

承認エンドポイントとトークンエンドポイントの両方がアクセストークンを発行しますが、アクセストークンの内容は常に同じであるとは限りません。これに関して、「3.3.3.8。 OpenID Connect Core1.0の「AccessToken」は次のように述べています。

承認エンドポイントとトークンエンドポイントの両方からアクセストークンが返される場合（response_type値のコードトークンとコードid_tokenトークンの場合）、それらの値は同じである場合と異なる場合があります。 2つのエンドポイントのセキュリティ特性が異なるため、異なるアクセストークンが返される場合があり、ライフタイムと、それらによって付与されるリソースへのアクセスも異なる場合があることに注意してください。

0
Canada Wan

承認コードフローと暗黙フローについてのあなたの考えは正しいです。しかし、あなたはハイブリッドフローを複雑にしすぎていると思います。ハイブリッドを使用する場合は、コードとid_tokenの両方を取得するだけです。

その後、コードを取得してアクセストークンと交換するか、id_token（またはアクセストークン）を直接使用することができます。どちらのアプローチにも、特にセキュリティの観点から、独自の欠点があります。

0
juanifioren