Oracle Cloud Infrastructureドキュメント

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

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

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

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トークンの取得: openidスコープを認可リクエストに含めることで、OAuth2付与タイプを使用してOpenID Connect IDトークンをリクエストします。

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

  2. IDトークンの検証: IDトークンを検証して、それが信頼できる発行者から取得されたこと、および転送中にコンテンツがタンパーされていないことを確認します。

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

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

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

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

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

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

ノート

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

OpenID Connect 1.0は、OAuth 2.0プロトコル上の単純なアイデンティティ・レイヤーです。これによって、クライアントIDとクライアント・シークレットを使用してOAuth 2クライアントとして登録されたIAMアイデンティティ・ドメイン・クライアント・アプリケーションは、認可サーバー(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* AuthNコンテキストからの認証強度を示すクラウド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エポック時間はJSON数値で、1970-01-01T0:0:0Zから協定世界時(UTC)で測定された日時までの秒数を表します。
iss トークンを発行したプリンシパル: https://<domainURL>
jti サーバー生成の、JWT IDの一意の識別子。
nonce クライアント・セッションをIDトークンに関連付けてリプレイ攻撃を軽減するために使用される文字列値。この値はCloud Gateによって提供されます。
session_exp* Cloud SSOセッションの期限が切れる時間(UNIXエポック時間)(秒、AuthNコンテキスト内で同じSSOのセッション有効期限である必要があります)。
sid AuthNコンテキストからのCloud SSOのセッションID (ASCII文字で最大255文字)。
sub ユーザーを識別します。サブジェクト識別子は、ローカルに一意で再割当てされることはありません。これは、クライアントのユーザー・ログインID (ASCII文字で最大255文字)で消費されることを目的としています。これは、AuthNコンテキストからのユーザーのログインIDです。
sub_mappingattr* IDストアでサブを検出するのに使用される属性。
tok_type* トークン・タイプを識別します: IT
user_displayname* AuthNコンテキストからのユーザー名(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スコープ 返されるクレーム

openid

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

プロファイル

名前、 family_name、 given_name、 middle_name、ニックネーム、 preferred_username、プロファイル、画像、 Webサイト、性別、生年月日、 zoneinfo、ロケール、 updated_at

アドレス

アドレス

電子メール

電子メール、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