認可コード権限付与タイプ

この認可フロー例では、認可コードを使用したOpenID Connectログイン・リクエストの流れを示しています。

このフローは、エンド・ユーザーのかわりにアプリケーションがアイデンティティ・ドメインAPIを呼び出し、場合によってはユーザー承諾が必要になるシナリオを参照する、3レッグのOAuthフローです。このフローは、OAuth 2.0およびOpenID Connectを使用して、アイデンティティ・ドメインとカスタム・アプリケーションの間でフェデレーテッド・シングル・サインオンを構成する方法を示しています。

アイデンティティ・ドメイン・コンソールで認可コード権限付与タイプを使用してアプリケーションを作成する場合:

• アプリケーションのタイプとして「信頼できるアプリケーション」を指定します。

• 権限付与タイプとして「認可コード」を選択します。

• 認証リクエストへのレスポンスの送信先になる「リダイレクトURI」を指定します。

• オプションで、リフレッシュ・トークンをアクセス・トークンで返すには、「Refresh Token」権限付与タイプを選択します。

認可コード権限付与タイプおよび認可フロー・ダイアグラムの詳細は、認可コード権限付与タイプを参照してください。

承認フロー

1. ユーザーはWebサーバー・クライアント・アプリケーション(顧客見積)でリンクをクリックし、保護されているリソースへのアクセスをリクエストします。

2. 顧客見積アプリケーションは、認可コードのリクエストを使用して、アイデンティティ・ドメイン認可エンドポイント(oauth2/v1/authorize)にブラウザをリダイレクトします。

   リクエストURLには、リクエストされているアクセスのタイプを示す問合せパラメータが含まれます。

   ノート
   
   nonce値は、インターセプトされたレスポンスが再利用されないようにするために使用する、暗号化された強力なランダム文字列です。

   リクエストの例: 機密/トラステッド・クライアント

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

   リクエストの例: 機密/トラステッド・クライアント(リクエストにリフレッシュ・トークンを含む)

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid%20<Resource
   Server Scope>%20offline_access&nonce=<nonce-value>&state=1234

   リクエストの例

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=id_token&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

   PKCEを使用したリクエストの例

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234&code_challenge=<code-challenge>&code_challenge_method=<plain|S256>'

3. アイデンティティ・ドメインは、リクエストを受信し、顧客見積アプリケーション(client_idで識別)がリソース所有者(スコープopenid).)の詳細情報を取得するために認可コードをリクエストしていることを識別します

4. ユーザーがまだログインしていない場合、IAMはユーザーの認証にチャレンジします。IAMはユーザーの資格証明をチェックします。

5. ログインに成功すると、IAMは認可コードとともにブラウザを顧客見積アプリケーションにリダイレクトします。

   ノート
   
   ユーザーが認証しない場合は、認可コードではなくエラーが返されます。

6. 顧客見積アプリケーションは、認可コードを抽出し、その認可コードとアクセス・トークンを交換するためのリクエストをアイデンティティ・ドメインに対して実行します。

   リクエストの例: 機密/トラステッド・クライアント

      curl -i 
      -H 'Authorization: Basic <base64-clientid-secret>' 
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' 
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-code>'

   リクエストの例: パブリック・クライアント

      curl -i 
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' 
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-code>&redirect_uri=<client-redirect-uri>&client_id=<client-id>'

   PKCEを使用したリクエストの例

      curl -i
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-cod>e&redirect_uri=<client-redirect-uri>&client_id=<client-id>&code_verifier=<code-verifier>'

7. IAMは、コード(client_id, client_secretおよび認可コード)に関連付けられた付与およびユーザー・データを検証します。

8. アクセス・トークンおよびアイデンティティ・トークンが返されます。アクセス・トークンには、ユーザーのかわりに顧客見積アプリケーションがリクエスト可能なスコープに関する情報が含まれます。アプリケーションでは、ユーザーのかわりにAPIをリクエストするときに、このトークンを使用できます。

   アイデンティティ・トークンが取得されるのは、openidスコープをリクエストした場合のみです。このトークンにはユーザーのID情報が含まれ、フェデレーション認証で使用されます。

9. 顧客見積アプリケーションによりid_tokenが処理され、IAMから返されたユーザーが抽出されます。

10. 顧客見積によってホーム ページが表示され、ユーザーに関する情報が表示されます。