付与タイプ

許可エンドポイント /authorize は、許可コードを返します。 その後、許可コードを ID トークン、アクセス・トークン、またはリフレッシュ・トークンと交換することができます。

クライアント ID および秘密鍵を使用してトークン・エンドポイント /token から ID トークンまたはアクセス・トークンを取得するには、クライアント認証が必要です。

これは最も一般的に使用されるフローです。

許可エンドポイント /authorize は、ID トークンまたはアクセス・トークンを直接返します。

許可コードもトークン・エンドポイント /token も使用しません。

これにより、クライアントのフロントエンドとバックエンドは互いに独立してトークンを受信できます。

クライアントは、許可エンドポイント /authorize から許可コードとトークンを取得します。 一部のトークンは、トークン・エンドポイント /token から要求されます。

Web アプリケーションやネイティブ・モバイル・アプリケーションなどの、クライアント秘密鍵をセキュアに維持できるクライアント に使用します。

これは、ユーザーおよびクライアントの認証を行うことを目的としています。

ブラウザーや JavaScript ベースのアプリケーションなどの、クライアント秘密鍵を保持できないクライアント に使用します。

これは、ユーザーを認証するためのものです。

code

id_token

token

id_token token

code id_token

code token

code id_token token

1. クライアントは、必要な要求パラメーターを含む認証要求を準備します。
2. クライアントは、認証サーバー Verify にリクエストを送信します。
3. 認証サーバーは Verify ユーザーを認証します。
4. 認証サーバーは Verify 、ユーザーから同意または承認を取得します。
5. 認証サーバーは Verify 、認証コードを添えてユーザーをクライアントに戻します。
6. クライアントは、トークン・エンドポイントで許可コードを使用して認証応答を要求します。
7. クライアントは、応答本体に ID トークンとアクセス・トークンを含む応答を受信します。
8. クライアントは、その ID トークンを検証し、ユーザーのサブジェクト ID を取得します。

1. クライアントは、必要な要求パラメーターを含む認証要求を準備します。
2. クライアントは、認証サーバー Verify にリクエストを送信します。
3. 認証サーバーは Verify ユーザーを認証します。
4. 認証サーバーは Verify 、ユーザーから同意または承認を取得します。
5. 認証サーバーは Verify 、IDトークン、および要求があればアクセストークンをユーザーに送信し、クライアントへ戻します。
6. クライアントは、その ID トークンを検証し、ユーザーのサブジェクト ID を取得します。

1. クライアントは、必要な要求パラメーターを含む認証要求を準備します。
2. クライアントは、認証サーバー Verify にリクエストを送信します。
3. 認証サーバーは Verify ユーザーを認証します。
4. 認証サーバーは Verify 、ユーザーから同意または承認を取得します。
5. 認証サーバーは Verify 、認証コードと、応答の種類に応じて1つ以上のパラメータをユーザーに含めてクライアントへ返します。
6. クライアントは、トークン・エンドポイントで許可コードを使用して応答を要求します。
7. クライアントは、応答本体に ID トークンとアクセス・トークンを含む応答を受信します。
8. クライアントは、その ID トークンを検証し、ユーザーのサブジェクト ID を取得します。

• クライアントとの信頼関係があるリソース所有者 (デバイスのオペレーティング・システム、特権の高いアプリケーションなど)。
• 対話式のフォームを使用してリソース所有者の資格情報 (ユーザー名とパスワード) を取得できるクライアント。
• 格納されている資格情報をアクセス・トークンに変換することによる、直接認証スキーム (HTTP 基本認証、ダイジェスト認証など) を使用する既存のクライアントの OAuth への移行。

1. ユーザーが、デバイスからクライアント ID を送信してユーザー・コードとデバイス・コードを要求することによってフローを開始します。
2. クライアント ID が有効な場合は、検証 URI、ユーザー・コード、およびデバイス・コードが返されます。
3. デバイスに、ユーザーがブラウザーに入力する検証 URI とユーザー・コード、またはユーザーがスキャンする QR コードが表示されます。
4. デバイスが継続的にトークンのデバイス・コードの交換を試行します。
5. ユーザーが検証 URI およびユーザー・コードをスキャンするか手動でキー入力し、OIDC サービスにユーザー・コードを送信します。
6. ユーザー・コードが有効な場合は、成功メッセージが送信され、デバイス・コードが交換されてアクセス・トークンが取得されます。

1. ユーザーが、依拠当事者のフォームに自分のユーザー名とパスワードを入力します。
2. クライアントが、トークン・エンドポイントにユーザー名、パスワード、クライアント ID、およびクライアント秘密鍵を送信します。
3. ユーザー名とパスワードが、クラウド・ディレクトリーに照らし合わせて検証されます。
4. 応答本文に ID トークンとアクセス・トークンが含まれている応答をクライアントが受信します。

1. クライアントが (任意の外部手段によって) JWT を取得してエンドポイントに提示します。
2. JWT が検証され、サブジェクトと追加の属性が抽出されます。
3. 応答本文に ID トークンとアクセス・トークンが含まれている応答をクライアントが受信します。

• 許可サーバーからのチャレンジ・タイプの応答を処理するために、クライアントをインスツルメントする必要があります。

• クライアントは、Verify 内で使用可能な認証要素 API を使用して JWTを受信します。この JWT は、フローを継続するために提供されます。
• クライアントは、「context」パラメーターによって要求にコンテキスト情報を追加する必要があります。

• なりすまし：クライアントが別のエンティティとしてリソースにアクセスすること。

• 委任：依頼人が、権限を与えられた者の代理として行動すること。

1. クライアントは、リクエストとともに何らかの `context` を提示することで、フローを開始します。 grant_type=Context-based authorization
2. クライアントは、DENY (このコンテキストでアクセスが許可されない場合) または CHALLENGE (返されたスコープで識別) を受け取ります。
3. クライアントは、チャレンジ応答で返されたアクセス・トークンを使用して、使用可能な認証要素 API (要素が完了した結果として JWT を要求するフラグを含む) にアクセスします。
4. 完了した要素から返された JWT が、JWT ベアラー付与要求として /token に再び提示され (コンテキストの包含も必要)、トークンが発行されます。

1. クライアントは、アクセストークンの有効期限が切れるか、すでに切れていることを検知し、新しいアクセストークンを取得しようとしています。
2. クライアントは、クライアント認証情報とリフレッシュトークンをトークンエンドポイントに送信します。
3. リフレッシュトークンとクライアント認証情報が検証されます。
4. クライアントは、レスポンス本文にIDトークン、リフレッシュトークン、およびアクセストークンが含まれたレスポンスを受け取ります。

1. クライアントは、サブジェクト・トークンとして使用するトークンを生成または取得します。 場合によっては、アクタートークンも含まれることがあります。

2. 対象トークン、および必要に応じてアクタートークンを添えて、認証サーバーのトークンエンドポイントにリクエストを送信します。

3. 認証サーバーは、要求されたトークンを返します。