Oracle Cloud Infrastructureドキュメント

OpenID Connectを使用したOAuth 2.0の拡張

OpenID Connectは、OAuth 2.0プロトコルを拡張して、簡易認証および単純なアイデンティティ・レイヤーをOAuth 2.0上に追加します。

クラウド・ベースのアプリケーションでアイデンティティ情報を取得し、認証イベントに関する詳細(認証のタイミング、場所、方法など)を取得し、フェデレーテッド・シングル・サインオン(SSO)を許可する場合は、OpenID Connectを使用します。

OAuth 2.0には、ユーザーのかわりにバックエンド・リソースを呼び出すときに使用するセキュリティ・トークンが用意されています。OAuthには、認証自体に関する情報を提供するのではなく、リソースにアクセスする権限またはライセンスが用意されています。認証にOAuthを使用することは、あなたの身元を確認したいと考えている人に、アパートの管理人が仮の鍵を渡すことに似ています。この鍵は、特定の時間だけアパートに入る権利のみを意味します。その人が所有者であることは意味しません。

OpenID Connectを使用すると、ユーザーに関する情報、その認証のコンテキスト、およびプロファイル情報へのアクセスがアプリケーションに提供され、全体像が完成します。OpenID Connectを使用すると、Webベース、モバイルおよびJavaScriptクライアントを含む全タイプのクライアントは、認証されたセッションおよびエンド・ユーザーに関する情報をリクエストして受け取ることができます。詳細は、OpenID Connectを参照してください。

次の2つの概念が導入されています:

  • OpenID Connect IDトークン: このトークンには、ユーザーの認証済セッションに関する情報が含まれます。

  • UserInfoエンドポイント: このエンドポイントは、クライアントがユーザーに関する追加属性を取得する方法を提供します。

OpenID Connectの実装

OpenID Connectを実装するには、次の3つの主要なアクションが必要です:

  1. OpenID Connect IDトークンの取得: OAuth2権限付与タイプを使用して、認可リクエストにopenidスコープを含めることでOpenID Connect IDトークンをリクエストします。

    次のユースケースでは、IDトークンを取得するためのリクエストおよびレスポンスの例を示します。

  2. IDトークンの検証: IDトークンを検証して、それが信頼できる発行者からのものであり、転送中にコンテンツが改ざんされなかったことを確認します。

    次のユースケースでは、検証方法と検証内容について説明します。

  3. UserInfoエンドポイントからのプロファイル情報の取得: OAuth2アクセス・トークンを使用して、UserInfoエンドポイントにアクセスし、認証されたユーザーに関するプロファイル情報を取得します。

    次のユースケースでは、UserInfoエンドポイントからプロファイル情報を取得するためのリクエストとレスポンスの例を示します。

アイデンティティ・トークン

アイデンティティ・トークンは、エンド・ユーザーに関するクレームを含むOpenID Connect標準で定義されている、整合性が確保された自己完結型のトークン(JSON Webトークン(JWT)形式です。アイデンティティ・トークンは、アイデンティティ・ドメインで認証を使用可能にするためのOpenID ConnectのOAuth 2.0に対する主要な拡張機能です。

アイデンティティ・トークンJWTは、ヘッダー、ペイロードおよびデジタル署名の3つのコンポーネントで構成されます。これらの3つのセクションは、JWT標準に従って、Base64URLでエンコードされ、ピリオドで区切られます。

ノート

OpenID Connectリクエストにはopenidスコープ値が含まれている必要があります。

OpenID Connect 1.0は、OAuth 2.0プロトコルの上にある単純なアイデンティティ・レイヤーです。これにより、IAMアイデンティティ・ドメイン・クライアント・アプリケーション(クライアントIDとクライアント・シークレットを使用してOAuth 2クライアントとして登録)は、認可サーバー(AS)によって実行される認証に基づいてエンド・ユーザーのアイデンティティを確認でき、相互運用可能でRESTなどの方法でエンド・ユーザーに関する基本プロファイル情報を取得できます。OpenID Connectを使用すると、Webベース、モバイルおよびJavaScriptクライアントを含む全タイプのクライアントは、認証されたセッションおよびエンド・ユーザーに関する情報をリクエストして受け取ることができます。詳細は、OpenID Connectを参照してください。

名前 値
amr 認証メソッドの参照。認証で使用される認証メソッドの識別子である文字列のJSON配列。たとえば、値はパスワードとOTP認証メソッドの両方が使用されたことを示す場合があります。
at_hash OAuth 2アクセス・トークン・ハッシュ値。
aud このIDトークンが対象とする受信者を識別します。(OpenID Connect仕様に従った) OAuth 2.0 client_idである必要があります。これは、リクエストを行うOAuthクライアント名(app.name)です。Audには、IAMアイデンティティ・ドメイン発行者も含まれているため、トークン・タイプ(IT)がIAMアイデンティティ・ドメインのユーザー・アサーションに変わります。
authn_strength* Cloud SSOから返され、認証コンテキストからの認証強度を示す値。
auth_time Cloud SSOがユーザーを実際に認証した時間(UNIXエポック時間)(秒単位、AuthNコンテキストから取得)。
azp 認可パーティ。IDトークンが発行されたパーティ。存在する場合、このパーティのOAuth 2.0クライアントIDが含まれている必要があります。このクレームは、IDトークンに単一のオーディエンス値があり、そのオーディエンスが認可されたパーティと異なる場合にのみ必要です。認可パーティが単独のオーディエンスと同じ場合でも含まれることがあります。azp値は、大/小文字を区別する文字列で、StringOrURI値が含まれます。
exp その時間以降は処理のためにIDトークンの受入れができなくなる有効期限(UNIXエポック時間)。この値は、session_exp.と同じである必要があります
iat JWTが作成された時間(UNIXエポック時間、秒単位)。UNIX Epoch Time is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in Coordinated Universal Time (UTC) until the date/time.
iss トークンを発行したプリンシパル: https://<domainURL>
jti サーバーで生成される、JWT IDの一意の識別子。
nonce クライアント・セッションをIDトークンに関連付けて、リプレイ攻撃を軽減するために使用される文字列値。この値はCloud Gateによって提供されます。
session_exp* Cloud SSOセッションの期限が切れる時間(UNIXエポック時間)(秒単位、認証コンテキスト内で同じSSOのセッション有効期限であることが必要)。
sid 認証コンテキストからのCloud SSOのセッションID (ASCII文字で最大255文字)。
sub ユーザーを識別します。サブジェクト識別子は、ローカルに一意で再割当てされることはなく、クライアントのユーザー・ログインID (ASCII文字で最大255文字)で消費されることを目的にはしています。これは、認証コンテキストからのユーザーのログインIDです。
sub_mappingattr* IDストアでサブを検索するために使用される属性。
tok_type* トークン・タイプを識別します: IT
user_displayname* 認証コンテキストからのユーザー表示名(ASCII文字で最大255文字)。
user_csr* (trueの場合)ユーザーはカスタマ・サービス担当(CSR)であることを指定します。
user_id* AuthNコンテキストからのユーザーのIAMアイデンティティ・ドメインGUID。
user_lang* ユーザーの優先言語。
user_locale* ユーザーのロケール
user_tenantname* ユーザー・テナント名(ASCII文字で最大255文字)。テナントのGUIDは、実際にはトークンに保存されません
user_tz* ユーザーのタイムゾーン。

アイデンティティ・トークン検証

トークンを検証する理由Webアプリケーションでは、資格証明を直接チェックするときに、表示されるユーザー名とパスワードが、保持しているユーザー名とパスワードに対応していることを確認します。クレーム・ベースのIDを使用する場合は、そのジョブをアイデンティティ・プロバイダにアウトソーシングします。

RAW資格証明の検証から、リクエスト元の優先アイデンティティ・プロバイダが経由して正常に認証されたことの確認への責任の変わります。アイデンティティ・プロバイダは、トークンを発行することで、認証が成功したことを表します。情報を使用する前、またはユーザーが認証したアサーションとして使用する前に、その情報を検証する必要があります。

OpenID検出文書

OpenID Connect 1.0プロトコルは、ユーザー情報、トークンおよび公開キーを含むリソースのリクエストとユーザーの認証に複数のエンドポイントを使用する必要がある、OAuth 2.0プロトコルの上にある単純なアイデンティティ・レイヤーです。これらのエンドポイントで、使用する必要があるエンドポイントを検出できるようにするために、OpenID Connectでは、既知の場所にあるJSONドキュメントである検出文書を使用できます。この検出文書には、認可、トークン、ユーザー情報および公開キー・エンドポイントのURIなど、OpenID Connectプロバイダの構成に関する詳細を提供するキー/値のペアが含まれます。IAMアイデンティティ・ドメインのOpenID Connectサービスの検出ドキュメントは、https://<domainURL>/.well-known/openid-configuration.から取得できます

アイデンティティ・トークンの検証

アイデンティティ(ID)トークンは、エンド・ユーザーに関するクレームを含む、整合性が確保された自己完結型のトークン(JSON Webトークン形式)です。認証されたユーザーのセッションを表します。したがって、アプリケーションがIDトークンの内容を信頼できるようにするには、トークンを検証する必要があります。たとえば、悪意のある攻撃者が以前に取得したユーザーのIDトークンをリプレイした場合、アプリケーションはトークンがリプレイされたこと、または期限切れになった後に使用されたことを検出し、認証を拒否する必要があります。

IDトークンはOpenID Connect標準で定義されており、認証を使用可能にするためのOpenID ConnectによるOAuth 2.0に対する主要な拡張機能です。IDトークンは機密性が高く、インターセプトされると誤用される可能性があります。これらのトークンは、HTTPS経由でのみ、POSTデータのみまたはリクエスト・ヘッダー内でのみ転送することで、安全に処理されるようにしてください。これらをサーバーに格納する場合も、安全に格納する必要があります。

  1. オーディエンス(aud)クレームの値に、アプリケーションのclient_id値が含まれることを検証します。aud (オーディエンス)クレームには、複数の要素を持つ配列を含めることができます。IDトークンに有効なオーディエンスとしてクライアントがリストされていない場合、またはクライアントから信頼されていない追加のオーディエンスが含まれる場合、IDトークンは拒否される必要があります。

  2. 現在の時刻が有効期限(exp)クレームで表される時刻より前であることを検証します。

  3. IDトークンが発行者によって正しく署名されていることを検証します。アイデンティティ・ドメイン発行トークンには、検出文書のjwks_uriフィールドで指定されたURIにある、いずれかの証明書を使用して署名されます。

    • SigningCert/jwkエンドポイント(たとえば、https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk)からテナントのパブリック証明書を取得します。

      ノート

      アイデンティティ・ドメインは公開キーを頻繁に変更しないため、公開キーをキャッシュして、ほとんどの場合、ローカル検証は効率的に実行できます。これには、証明書の取得と解析、および署名をチェックするための適切な暗号コールが必要です:

    • 検証に使用可能なJWTライブラリを使用します(たとえば、Connect2idのJava用Nimbus JWTライブラリ)。使用可能なライブラリのリストは、「JWT」を参照してください。

      ノート

      署名検証が失敗した場合、bogusトークンを使用した攻撃に対する再フェッチが常に実行されるようにするには、一定の時間間隔に基づいて公開キーの再フェッチ/再キャッシュを実行する必要があります(例- 60分)。これにより、再ファンクションは60分ごとに実行されます。

    例

    package sample;
 
import java.net.MalformedURLException;
import java.net.URL;
 
import com.nimbusds.jose.JWSAlgorithm;
import com.nimbusds.jose.jwk.source.JWKSource;
import com.nimbusds.jose.jwk.source.RemoteJWKSet;
import com.nimbusds.jose.proc.JWSKeySelector;
import com.nimbusds.jose.proc.JWSVerificationKeySelector;
import com.nimbusds.jose.proc.SecurityContext;
import com.nimbusds.jwt.JWTClaimsSet;
import com.nimbusds.jwt.proc.ConfigurableJWTProcessor;
import com.nimbusds.jwt.proc.DefaultJWTProcessor;
 
public class TokenValidation {
 
    public static void main(String[] args) {
        try {
            String tokenValue = "eyJ4NXQjUzI1....W9J4oQ";
     
            ConfigurableJWTProcessor jwtProcessor = new DefaultJWTProcessor();
 
            // change t
            JWKSource keySource = new RemoteJWKSet(new URL("https://<domainURL>/admin/v1/SigningCert/jwk"));
 
            // The expected JWS algorithm of the token (agreed out-of-band)
            JWSAlgorithm expectedJWSAlg = JWSAlgorithm.RS256;
 
            // Configure the JWT processor with a key selector to feed matching public
            // RSA keys sourced from the JWK set URL
            JWSKeySelector keySelector = new JWSVerificationKeySelector(expectedJWSAlg, keySource);
            jwtProcessor.setJWSKeySelector(keySelector);
 
            // Process the token
            SecurityContext ctx = null; // optional context parameter, not required here
            JWTClaimsSet claimsSet = jwtProcessor.process(tokenValue, ctx);
            // Print out the token claims set
            System.out.println(claimsSet.toJSONObject());
             
 
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
 
}

  4. 発行者識別子(iss)クレームの値がiss (発行者)クレームの値(https://<domainURL>/)と完全に一致することを検証します

UserInfoエンドポイントの問合せ

OpenID Connect UserInfoエンドポイントは、認証されたアイデンティティに関するプロファイル情報を取得するためにアプリケーションによって使用されます。アプリケーションは、このエンドポイントを使用して、プロファイル情報、プリファレンスおよびその他のユーザー固有の情報を取得できます。

OpenID Connectプロファイルは、次の2つのコンポーネントで構成されます:

  • ユーザーを説明するクレーム

  • これらのクレームを取得するメカニズムを提供するUserInfoエンドポイント
    ノート

    ユーザー・クレームはIDトークン内に表示して、認証時のコールバッグを不要にする必要があります。

ユーザー・プロファイル・クレーム

UserInfoエンドポイントでは、認証リクエストで表示されたOAuth2スコープに基づいてクレームのセットを提供します。OpenID Connectでは、デフォルトのクレームの特定のセットにマップする5つのスコープ値を定義します:

OpenID Connectスコープ 返されるクレーム

オープンID

なし - これがOpenID Connectリクエストであることを示します

プロファイル

name、family_name、given_name、middle_name、nickname、preferred_username、profile、picture、website、gender、birthdate、zoneinfo、locale、updated_at

住所

住所

Eメール

email、email_verified

電話番号

phone_number、phone_number_verified

クライアントは、資格証明とアクセス・トークンを表示する必要があります。表示されるアクセス・トークンには、openidスコープが含まれている必要があります。

スコープが省略された場合(たとえば、emailスコープが使用されない場合)、返されるクレームにクレーム(email)は存在しません。

サンプルUserInfoエンドポイント・リクエストの例

クライアント・アプリケーションがユーザーを認証し、アクセス・トークンを取得した後、クライアントはUserInfoエンドポイントにリクエストして、ユーザーに関するリクエスト済の属性を取得できます。次の例は、リクエストの例を示しています。 

   curl -i
   -H 'Content-Type: application/x-www-form-urlencoded'
   -H 'Authorization: Bearer eyJ4NXQjUzI1....rtApFw'-H 'Accept: */*'
   -H 'Content_Language: en-US'--request GET https://<domainURL>/oauth2/v1/userinfo

レスポンスの例

レスポンスに成功すると、HTTP 200 OKレスポンスとユーザーのクレームがJSON形式で返されます:

{
"birthdate":"",
"email":"user@example.com",
"email_verified":false,
"family_name":"user",
"gender":"",
"given_name":"user",
"appRoles":[],
"name":"alice alice",
"preferred_username":"user@example.com",
"sub":"user@example.com",
"updated_at":1495136783,"website":""
}

クライアント・アプリケーションがUserInfoエンドポイントから返された値を信頼できるようにするには(たとえば、トークン置換攻撃のチェックとして)、UserInfoエンドポイント・リクエストから返されたsubクレームがIDトークンのサブジェクトと一致することを検証する必要があります。

OpenID Connectでの認可コード・フローの使用

認可コード・フローは、自身と認可サーバー間のクライアント・シークレットを安全に維持できるクライアントがある場合に使用します。認可コード・フローはクライアントに認可コードを返し、クライアントはIDトークンとアクセス・トークンのコードを直接交換できます。

これにより、トークンがユーザー・エージェント(Webブラウザなど)に公開されず、ユーザー・エージェントにアクセス使用とする悪意のある他のアプリケーションにも公開されないというメリットが得られます。認可サーバーでは、認可コードをアクセス・トークンと交換する前にクライアントを認証することもできます。認可コード・フローは、機密クライアントとパブリック・クライアントの両方で機能します。

機密クライアント

認可コード・フローには、次の2つのステップがあります:

  1. 認可コードをリクエストします。このリクエストでは、スコープ・パラメータ値はopenid.ですこれはOpenID Connect仕様値です。

    リクエストの例

    https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid

    レスポンスの例

    https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

    • リクエストに追加のスコープ値を指定できます。たとえば:

      https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=phone+openid+offline_access+profile+address+email

    • このリクエストには、openidとOAuthリソース・スコープの両方が含まれます:

      https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=http://<domainURL>/api+openid

  2. トークンをリクエストします。クライアントは、レスポンスからコード・パラメータを抽出し、トークン・リクエストを作成します。また、クライアントは、基本認証ヘッダーの一部としてクライアントIDおよびシークレットを提供します。

    リクエストの例

       curl -i
   -H 'Authorization: Basic ZWE1OGIwNDA0N2ZkNGQ4MTgyYThiYWQ0ZTNkMGFmZjU6ZGMxNGE4MjMtZGU2OC00YWNhLTg1OWUtMWNhZTJmNjQ0NTBi' 
   -H 'Accept: */*'
   --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAXv9lZQ???.jF9NCA'

    レスポンスの例

    リクエストには、アクセス・トークンとIDトークンの両方が含まれます。

    {
"access_token":"eyJ4NXQjUzI1???.xhtnbw",
"token_type":"Bearer",
"expires_in":27261,
"id_token":"eyJ4NXQjUzI1???.._XLqUw"
}

パブリック・クライアント

パブリック・クライアントには、資格証明ではなく、クライアント識別子が含まれます。認可コード・フローには、次の2つのステップがあります。リクエストには、ブラウザベースのGETリクエストと、アクセス・トークンを取得するためのバックチャネルPOSTリクエストが含まれます。

  1. 認可コードをリクエストします。

    リクエストの例 

    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

    レスポンスの例

    ノート

    これらのリクエストおよびレスポンスの例は、前述の機密クライアントのリクエストおよびレスポンスに似ています。
    https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

  2. トークンをリクエストします。

    リクエストの例

    ノート

    このリクエストは、基本認証ヘッダーにクライアントIDおよびクライアント・シークレットが指定されている機密クライアントのリクエストとは異なります。パブリック・クライアント・フローでは、基本認証ヘッダーはありません。クライアントIDは、リクエスト・ペイロードの一部として指定されます。
       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>&reidrect_uri=<client-redirect-uri>&client_id=<client-id>'

    レスポンスの例 

    {
"access_token":"eyJ4NXQjUzI1???.xhtnbw",
"token_type":"Bearer",
"expires_in":27261,
"id_token":"eyJ4NXQjUzI1???.._XLqUw"
}

OpenID Connectでの暗黙的なフローの使用

JavaScriptなどのスクリプト言語を使用して、ブラウザベースのクライアントを実装した場合は、暗黙的なフローを使用します。アクセス・トークンおよびIDトークンがクライアントに直接返され、ユーザーはユーザーのユーザー・エージェント(Webブラウザなど)にアクセスできるアプリケーションとアプリケーションに、これらのトークンを公開できます。

このフローには、(認可コード・フローの例のパブリック・クライアント・リクエストと同様)プログラムによる/バックチャネル・トークン・リクエストはありません。すべてのトークンがAuthorizationエンドポイントから返され、tokenエンドポイントは使用されません。暗黙的なフローは、機密クライアント、トラステッド・クライアントおよびパブリック・クライアントで機能します。
ノート

パブリック・クライアントには資格証明がなく、クライアント識別子のみです。

暗黙的なフローでは、次のresponse_type値がサポートされています:

  • id_token (IDトークン)

  • token (アクセス・トークン)

  • id_token token (IDトークンとアクセス・トークンの両方)

IDトークンの取得

暗黙的なフローには、IDトークンを取得するための3つのステップがあります:

  1. トークンをリクエストします。

    リクエストの例

    https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=id_token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile&nonce=abcdefg

  2. ユーザーがログインし、(リクエストされたスコープに基づいて)承諾を得ます

  3. IDトークンでレスポンスします

    レスポンスの例

    ノート

    すべてのレスポンス・パラメータがリダイレクションURIのフラグメント・コンポーネントに追加されます。
    https://<domainURL>/#id_token=eyJ4NXQjUzI1.....gF5uyQ

アクセス・トークンの取得

暗黙的なフローには、アクセス・トークンを取得するための3つのステップがあります:

  1. アクセス・トークンをリクエストします。

    リクエストの例 

    https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile

  2. ユーザーがログインし、(リクエストされたスコープに基づいて)承諾を得ます。

  3. アクセス・トークンでレスポンスします

    レスポンスの例

    ノート

    すべてのレスポンス・パラメータがリダイレクションURIのフラグメント・コンポーネントに追加されます。
    https://<domainURL>/#access_token=eyJ4NXQjUzI1...4WGvJQ&token_type=Bearer&expires_in=3600

IDトークンとアクセス・トークンの取得

暗黙的なフローには、IDトークンとアクセス・トークンの両方を取得するための3つのステップがあります:

  1. IDトークンおよびアクセス・トークンをリクエストします。

    リクエストの例
    https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=id_token token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile&nonce=abcdefghijkl

  2. ユーザーがログインし、(リクエストされたスコープに基づいて)承諾を得ます。

  3. アクセス・トークンおよびIDトークンを使用したレスポンス。

    レスポンスの例
    ノート

    すべてのレスポンス・パラメータがリダイレクションURIのフラグメント・コンポーネントに追加されます。
    https://<domainURL>/#access_token=eyJ4NXQjUzI....XWGmeQ&id_token=eyJ4NXQjUzI1....&token_type=Bearer&expires_in=3600

OpenID Connectでのハイブリッド・フローの使用

フロント・チャネルとバック・チャネルの両方から個別にトークンを取得する場合は、ハイブリッド・フローを使用します。たとえば、JavaScriptなどのブラウザ・コンポーネントとNode.jsなどのバックエンド・サーバー・コンポーネントがあるとします。ブラウザ・コンポーネントは、認可コードとIDトークンを取得し、UIコンテンツをパーソナライズできます。バックエンド・コンポーネントは、ビジネスAPIコールを実行するためのアクセス・トークンを取得します。

クライアントは、ハイブリッド・フローを使用するために、ブラウザベースのリクエストとレスポンス、およびプログラムによる/バックチャネルのリクエストとレスポンスの両方をサポートする必要があります。ハイブリッド・フローは、機密クライアントとパブリック・クライアントの両方で機能します。ハイブリッド・フローでは、次のresponse_type値がサポートされています:

  • code id_token (IDトークン)

  • code token (アクセス・トークン)

  • code id_token token (認可コード、IDトークンおよびアクセス・トークン)

IDトークンの取得

ハイブリッド・フローには、認可コードとIDトークンの両方を取得するための4つのステップがあります:

  1. 認可コードおよびIDトークンをリクエストします。

    リクエストの例

    https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code id_token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test+openid+offline_access&nonce=abcdefghijk

  2. ユーザーがログインし、(リクエストされたスコープに基づいて)承諾を得ます。

  3. IDトークンと認可コードでレスポンスします。

    レスポンスの例

    ノート

    すべてのレスポンス・パラメータがリダイレクションURIのフラグメント・コンポーネントに追加されます。
    https://<domainURL>/#code=AQIDBAUrAi0l....F9NCA=&id_token=eyJ4NXQjUzI1....3R8b_Q

  4. クライアント・アプリケーションは、認可コードを使用してバック・チャネル・リクエストを行い、新しいアクセス・トークンとリフレッシュ・トークンを取得します。

    リクエストの例

       curl -i
   -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
   -H 'Accept: */*'
   --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAUrAi0l???.CA%3D'

    レスポンスの例

    {
"access_token":"eyJ4NXQjUzI1....sJ5mCw",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"AQIDBAUwxxoC....tZLvA"
}

アクセス・トークンの取得

ハイブリッド・フローには、認可コードとアクセス・トークンを取得するための4つのステップがあります:

  1. 認可コードおよびアクセス・トークンをリクエストします。

    リクエストの例 

    https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test

  2. ユーザーがログインし、(リクエストされたスコープに基づいて)承諾を得ます。

  3. IDトークンと認可コードでレスポンスします。

    レスポンスの例

    ノート

    すべてのレスポンス・パラメータがリダイレクションURIのフラグメント・コンポーネントに追加されます。
    https://<domainURL>/#access_token=eyJ4NXQjUzI1....Pudw9A&code=AQIDBAU6d6Ae....F9NCA=&token_type=Bearer&expires_in=3600

  4. クライアント・アプリケーションは、認可コードを使用してバック・チャネル・リクエストを行い、新しいアクセス・トークンを取得します。

    リクエストの例 
       curl -i
  -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
   -H 'Accept: */*''
   --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAU6d6Ae...NCA%3D'

    レスポンスの例 

    {
"access_token":"eyJ4NXQjUzI1....Tgs9LA",
"token_type":"Bearer",
"expires_in":3600
}

IDトークンおよびアクセス・トークンの取得

認可コード、IDトークンおよびアクセス・トークンを取得するための4つのステップがハイブリッド・フローにあります。

  1. 認可コードおよびIDトークンをリクエストします。

    リクエストの例
    https://<domainURL>/oauth2/v1/authorize?client_id=client_id&response_type=cod id_token token&redirect_uri=client_redirect_uri&scope=http://<domainURL>/test+openid&nonce=abcdaer

  2. ユーザーがログインし、(リクエストされたスコープに基づいて)承諾を得ます。

  3. IDトークンおよびアクセス・トークンを使用したレスポンス。

    レスポンスの例
    ノート

    すべてのレスポンス・パラメータがリダイレクションURIのフラグメント・コンポーネントに追加されます。
    https://<domainURL>/#access_token=eyJ4NXQjUzI1....sDB7lA&code=AQIDBAVxZzy-....F9NCA=&id_token=eyJ4NXQjUzI1....&token_type=Bearer&expires_in=36004

  4. クライアント・アプリケーションは、認可コードを使用してバック・チャネル・リクエストを行い、新しいアクセス・トークンを取得します。

    リクエストの例
       curl -i
   -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
   -H 'Accept: */*' ?request
   POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAXUbLmS???.NCA%3D'

    レスポンスの例

    {
"access_token":"eyJ4NXQjUzI1....g52XmQ",
"token_type":"Bearer",
"expires_in":3600,
"id_token":"eyJ4NXQjUzI1....f6JfWA"
}

OpenID Connectを使用したログアウト

OpenID Connectは、ブラウザベースのログアウト・リクエストに使用できます。

OpenID Connectを使用してログアウトをリクエストできる2つの方法があります:

  1. ログアウトを開始したクライアントにリダイレクトします。

    ノート

    OAuthクライアント・アプリのログアウト後のリダイレクトURIを定義し、IDトークンがリクエストで送信されることを確認してください。IDトークンには、クライアントIDが含まれています。そのクライアントIDに対応するログアウト後のURLがフェッチされ、検証されます。

    リクエストの例 

    https://<domainURL>/oauth2/v1/userlogout?post_logout_redirect_uri=http://clienthost:port/myapp/return&state=c3004d28&id_token_hint=<IDToken>

  2. テナントのランディング・ページを使用します。

    ノート

    これは、テナントのSSO設定で設定されたテナントのランディング・ページを使用します。

    リクエストの例 

    https://<domainURL>/oauth2/v1/userlogout