OpenID Connect の認可エンドポイントの起動

OpenID Connect では、認可エンドポイントがユーザーの認証および認可を扱います。

始める前に

認可エンドポイントの開始を、ブラウザー内クライアント・アプリケーションから、または、スクリプト言語 (JavaScript など) に実装されたクライアント・アプリケーションから行う場合、OpenID Connect クライアントとしての Liberty サーバーの構成は必要ありません。

このタスクについて

認可エンドポイントは、OAuth 2.0 仕様と OpenID Connect 1.0 仕様の両方で規定されているパラメーターを含む認証要求を受け入れます。

Authorization Code Flow では、 認可エンドポイントは、認証および認可のために使用され、クライアントに認可グラントを返します。その後、クライアントは、この認可グラントを要求に入れて、 ID トークン、アクセス・トークン、およびリフレッシュ・トークンと交換に、トークン・エンドポイントに渡すことができます。Implicit Flow では、 認可エンドポイントは、認証および認可を実行するだけでなく、ID トークンおよびアクセス・トークンを応答に入れて直接クライアントに返すこともするため、 トークン・エンドポイントとの間では何もやりとりされません。

OpenID Connect が有効になった Liberty サーバーは、以下の URL で OpenID Connect 認可エンドポイントにアクセスできます。

 https://server.example.com:443/oidc/endpoint/<provider_name>/authorize
注: この例では、 OP の SSL ポートは 443 であると想定されています。

手順

  1. 以下の必須パラメーターおよび推奨パラメーターを含む HTTP GET または POST 要求を準備します。
    • scope: (必須) OpenID Connect 要求は openid スコープ値を含んでいなければなりません。それ以外のスコープが存在していてもかまいません。
    • response_type: (必須) これは、使用される認可プロセス・フローを決定します。Authorization Code Flow を使用する場合、 この値は code です。Implicit Flow を使用する場合、 この値は id_token token または id_token です。 値が id_token の場合、アクセス・トークンは返されません。
    • client_id: (必須) OpenID Connect プロバイダーで有効なクライアント ID。
    • redirect_uri: (必須) 応答が送信される先のリダイレクト URI。この値は、 OP に登録済みのクライアントのリダイレクト URI 値の 1 つと完全に一致する必要があります。
    • state: (推奨) 要求とコールバックとの間で状態を保守するために使用される不透明な値。
    • nonce: (Implicit Flow の場合は必須) クライアント・セッションと ID トークンを関連付けるため、およびリプレイ・アタック対策のために使用されるストリング値。

    要求にさらに別のパラメーターを含めることができます。サポートされている他のパラメーターの説明については、OpenID Connect Core 1.0 仕様を参照してください。

    当製品では id_token response_type のみサポートしていません。Implicit Flow を使用する場合は常に id_token token を使用する必要があり、アクセス・トークンが返されます。

  2. GET または POST 要求を認可エンドポイント URL に送信します。

タスクの結果

上の手順を完了すると、認可エンドポイントに送信される有効な HTTP 要求が生成されます。認可エンドポイントは、 『例』セクションに説明されているように、応答を返します。

OpenID Connect プロバイダーは、クライアントから要求を受け取ると、 ユーザーを認証および認可しようとします。

Authorization Code Flow では、 認証および認可が成功した場合、OpenID Connect プロバイダーは認可コードを発行し、 そのコードをクライアントへの OAuth 2.0 認可応答にパラメーターとして組み込みます。初期要求が state を含んでいた場合、 認可応答にも初期要求に含まれていたのとまったく同じ state 値が含まれます。application/x-www-form-urlencoded 形式を使用して、 code パラメーターおよび state パラメーターが、 認可要求に指定された redirect_uri 値に照会パラメーターとして追加されます。

Implicit Flow では、 認証および認可が成功した場合、以下のパラメーターが認可エンドポイントから返されます。

  • access_token: アクセス・トークン。初期要求の [response_type] 値が [id_token] でない場合、これが返されます。
  • token_type: OAuth 2.0 トークン・タイプ。OpenID Connect では、この値は Bearer です。
  • id_token: ID トークン。
  • state: 認可要求に含まれる場合は必須。
  • expires_in: (オプション) 応答が生成されてからのアクセス・トークンの有効期限 (秒単位)。

これらのパラメーターは、 Authorization Code Flow でのように照会パラメーターとしてではなく、認可要求に指定された redirect_uri 値のフラグメント・コンポーネントに追加されます。

以下の例は、Authorization Code Flow と Implicit Flow の形式を示します。

Authorization Code Flow の要求例は次のとおりです。

 GET /authorize?
     response_type=code
     &scope=openid profile email 		
     &client_id=client01 		
     &state=af0ifjsldkj 		
     &redirect_uri=https://server.example.com:8020/oidcclient/redirect/client01 HTTP/1.1 	

Implicit Flow の要求例は次のとおりです。

 GET /authorize?
     response_type=id_token token
     &scope=openid profile 		
     &client_id=client01 		
     &state=af0ifjsldkj 		
     &redirect_uri=https://server.example.com:8020/oidcclient/redirect/client01 		
     &nonce=n-0S6_WzA2Mj HTTP/1.1 	

Authorization Code Flow における認可エンドポイントからの応答例は次のとおりです。

 HTTP/1.1 302 Found
 Location: https://server.example.com:8020/oidcclient/redirect/client01
     code=SplxlOBeZQQYbYS6WxSbIA
     &state=af0ifjsldkj

Implicit Flow における認可エンドポイントからの応答例は次のとおりです。

 HTTP/1.1 302 Found
 Location: https://server.example.com:8020/oidcclient/redirect/client01
     access_token=SlAV32hkKG
     &token_type=Bearer 		
     &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso 		
     &expires_in=3600 		
     &state=af0ifjsldkj

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: Monday, 5 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=twlp_oidc_auth_endpoint
ファイル名: twlp_oidc_auth_endpoint.html