このページは Authlete 3.0 用です。2.x についてはこちらのページをご覧ください。
はじめに
このドキュメントは、Authlete APIs を使用して、認可コードフロー をサポートする OpenID Connect (OIDC) アイデンティティプロバイダー (IdP) サーバーを実装する基本的な使用方法を説明するためのチュートリアルです。 このチュートリアルを完了すると、以下を実施できます:- 認可サーバーから Authlete へのリクエストをシミュレーションしながら、Authlete API へのリクエストを送信します。
- 認可リクエストで追加のクレームを含む発行者識別子の値を Authlete 管理コンソールに設定し、それらが ID トークンからデコードされる様子を確認します。
認可コードフローのコンポーネント
Noteこのチュートリアルでは便宜上、OIDC アイデンティティプロバイダーを「認可サーバー」、同リライングパーティを「クライアント」と表記します。
curl コマンドを使用してこれらのリクエストを直接行います。もちろん、PowerShell や Postman など、別の HTTP クライアントを使用することもできますが、その場合は手順を適宜調整する必要があります。
この OAuth フロー内で各コンポーネントがどのように連携するかを理解するために、各コンポーネントの完全修飾ドメイン名 (FQDN) を以下に示します。認可サーバーとクライアントの FQDN は参考用に作成されたものであり、実際の実装では適切な値に置き換える必要があります
NoteAPI エンドポイントはクラスターごとに異なります。他のクラスターのサービスを使用する場合は、そのクラスターの ISO コードを完全なドメイン名に置き換える必要があります (例: br, eu, jp)。
環境設定
Noteこのセクションの設定は、Authlete API チュートリアル「OAuth 2.0 の基本」に記載されている内容と同じです。このチュートリアルをすでに完了している場合は、このセクションをスキップできます。
以下の値を使用してクライアントを作成し、他のすべてのフィールドはデフォルトのままにしてください。
クライアントを作成したら、クライアント設定 > エンドポイント > 基本設定に移動します。リダイレクト URI セクションで [追加] をクリックし、クライアントが認可レスポンスを受け取る URI を入力して保存します。
以下はクライアントを作成したときに生成または指定されたプロパティの例です。これらの値は、認可コードフローの一環としてリクエストを行う際に必要となります。環境設定セクションで記録した値を使用してください。
これで、この環境を使用して OIDC 認可コードフローを試す準備が整いました。
ウォークスルー
以下のシーケンス図を提供して、コードフローに関与する各ステップを理解できるようにしています。このウォークスルー内の位置を確認するため、対応する番号を使用してステップを識別できます。クライアントから認可サーバーへの認可リクエスト
以下の値を例としてリクエストのパラメータに使用します (前述の通り)。
リソースオーナーがクライアントを介して保護されたリソースにアクセスしようとすると (ステップ #1、#2)、クライアントはユーザーエージェントを介して認可リクエスト (OIDC 認証リクエスト) を認可サーバーに送信します (ステップ #3、#4)。
認可サーバーは、以下に示すように、ユーザーエージェントから HTTP
GET クエリ文字列としてデータを受け取ります。
- クライアント ID
12898884596863に関連付けられたクライアントが認可サーバーに登録されているかどうか。scope=openidの場合、このクライアントは OIDC リライングパーティである必要があります。 - リダイレクト URI
https://client.example.org/cb/example.comの値が、クライアントに登録された URI の一つと一致しているかどうか。 response_typeやscopeなどの他のパラメータの値が、クライアントに対して許可されているかどうか。
scope と response_type の値がそれぞれ openid と code であるため、認可サーバーは OIDC 認可コードフローを処理します。
ただし、Authlete アーキテクチャでは、認可サーバーは単に Authlete API によって処理される認可ロジックのプロキシとして機能します。このロジックは /auth/authorization エンドポイントで公開されています。リクエストを受け取ると、Authlete API が認可サーバーに代わって評価プロセスを実行します。
ここから、認可サーバーのリクエストをこの API にシミュレートします。
以下のように curl コマンドを実行してください (メッセージ #5)。前のステップで生成した <サービス ID> (Service ID)、<サービス アクセス トークン> (Service Access Token)、および <クライアント ID> (Client ID) を置き換えて使用します。
resultMessage、action、ticket の 3 つのキー/値ペアに注意してください。
resultMessage: リクエスト処理の結果を人間が読める形式で提供します(詳細は Authlete の結果コードの解釈 を参照)。openid=trueは、リクエストが OIDC プロトコルに従って処理されることを示します。action: 認可サーバーが次に行うべきアクションを示します(詳細は アクションハンドリング を参照)。ticket: 次のステップで別の API にリクエストを行うために必要です(詳細は 2 段階の API 呼び出し を参照)。
ユーザー認証と認証結果の共有確認
リソースオーナーと認可サーバー間の実際のやり取りは、このチュートリアルの範囲外です。通常、認可サーバーは以下のプロセスを実行します:- 資格情報 (例: ID/パスワード) を使用してユーザーを認証します。
- ユーザーのロールや権限を決定します。
- ユーザーに、認証結果をクライアントと共有するかどうかを確認します。
認可コードの発行
次に進む前に、認可サーバーが以下の状態にあると仮定します:- 認可サーバーがリソースオーナーを認証し、
subjectパラメータとして Authlete に共有されるリソースオーナーの識別子がtestuser01であることを決定した。 - 認可サーバーがリソースオーナーの同意を取得した。
/auth/authorization/issue にリクエストを送信し、認可コードを発行します。このリクエストには、subject と /auth/authorization API のレスポンスに含まれる ticket の値が含まれます。
以下の curl コマンドを実行してください (メッセージ #10)。先ほど生成した <Service ID>、<Service Access Token>、および <Ticket> を置き換えて使用します。
resultMessage、action、responseContent の 3 つのキー/値ペアに注目してください。
resultMessage: リクエスト処理の結果を人間が読める形式で提供します(詳細は Authlete の結果コードの解釈 を参照)。action: 認可サーバーが次に行うべきアクションを示します。このレスポンスの値はLOCATIONであり、認可サーバーがユーザーエージェントにリダイレクトレスポンスを返すべきことを示しています(詳細は アクションハンドリング を参照)。responseContent: 認可サーバーからのレスポンス内容を示します(詳細は アクションハンドリング を参照)。
認可コードの発行に失敗した場合
場合によっては、認可サーバーがリソースオーナーから認可を受けられないことがあります。この場合、クライアントにトークンを発行せず、認可フローが終了したことを通知する必要があります。Authlete の/auth/authorization/fail API は、クライアントに送信されるメッセージおよびレスポンスの転送方法の観点から、この終了プロセスをサポートします。
まとめると、通常の状況では、認可サーバーはユーザー認証と同意の結果に応じて、/auth/authorization/issue または /auth/authorization/fail API のいずれかにリクエストを送信します。
トークンリクエスト
ここでは、ユーザーエージェントが認可サーバーからのリダイレクトレスポンスを受け取ったと仮定します。このリダイレクトレスポンスは以下のようにクライアントに転送されます (ステップ #13)。code パラメータの値を抽出し、それを使用してトークンリクエストを構築し、認可サーバーに送信します。以下はその例です (改行を追加して可読性を向上させています)。https://as.example.com/token は、このチュートリアルにおけるトークンエンドポイント URI です (ステップ #14)。
/auth/token API を使用します。この API はリクエストを評価し、レスポンスを生成します。
以下の curl コマンドを実行してください (ステップ #15)。先ほど生成した <Service ID>、<Service Access Token>、<Client ID>、<Client Secret>、および <Code> を置き換えて使用します。
resultMessage、action、responseContent の 3 つのキー/値ペアに注目してください。
resultMessage: リクエスト処理の結果を人間が読める形式で提供します(詳細は Authlete の結果コードの解釈 を参照)。action: 認可サーバーが次に行うべきアクションを示します。この場合の値はOKであり、認可サーバーがクライアントにトークンレスポンスを返すべきことを示しています(詳細は アクションハンドリング を参照)。responseContent: 認可サーバーからクライアントへのレスポンス内容を示します(詳細は アクションハンドリング を参照)。
ID トークンのデコード
クライアントは、レスポンス内のid_token の値をデコードし、その有効性を確認する必要があります。
このチュートリアルでは、無料のオープンソースツール Online JWT Verifier を使用してトークンをデコードします。
以下のリンクを開き、JWT Verifier UI の (Step 1) Set JWT (JSON Web Token) to verify テキストエリアに id_token の値を貼り付けてください。このチュートリアルの例では ID
トークンの値として eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU5MTA2ODE1LCJpYXQiOjE1NTkwMjA0MTUsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.5uSFMTGnubyvtiExHc9l7HT9UsF8a_Qb0STtWzyclBk を使用します。
その後、(Step 3) Verify セクション内の Just Decode JWT ボタンをクリックして、Parsed JWT セクションにデコードされた内容を確認してください。
デコード結果は以下のようになります。
ヘッダー:
issがhttps://authlete.comとなっていますが、これは Authlete のデフォルト値です。このチュートリアルでは、認可サーバーの識別子としてhttps://as.example.comにする必要があります。subはユーザーの識別に関する唯一の属性です。クライアントの利便性のために、他のユーザー属性を追加することが望ましいです。
iss の値を修正し、追加のクレームを追加します。
ID トークンの修正
発行者識別子の設定
https://console.authlete.com にログインし、このチュートリアルで作成した Demo AS サービスを選択します。サービス設定 ボタンをクリックして、サービス設定にアクセスします。 一般 タブにある 発行者識別子 のデフォルト値がhttps://authlete.com であることに注意してください。この値を https://as.example.com に変更し、ページ下部の 変更を保存 ボタンをクリックして保存します。
確認ダイアログが表示されたら OK をクリックします。
これで、ID トークンの発行者識別子 iss が修正されました。
認可リクエストの送信
先ほどと同じ認可リクエストを送信します (便宜上、同じnonce 値を使用します)。このリクエストは Authlete の /auth/authorization API に送信されます (ステップ #5)。以下のように <Service ID>、<Service Access Token>、および <Client ID> を置き換えて使用してください。
追加クレームの追加
次に、認可コードを発行するために Authlete の/auth/authorization/issue API にリクエストを送信します。このリクエストに含まれるクレームには以下の追加項目を含めます。
以下の
claims パラメータを使用してクレームを追加します。リクエストは以下のように構築されます。
GET リクエストをクライアントに送信します。
トークンリクエストの送信
クライアントは以下のようにトークンリクエストを認可サーバーに送信します (改行は可読性向上のため追加されています)。/auth/token API を呼び出します。
id_token の値を Step 1 のテキストエリアに貼り付けます。このチュートリアルでは ID トークンの値として eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0 を使用します。
その後、Step 3 の Just Decode JWT ボタンをクリックし、Parsed JWT セクションでデコードされた内容を確認してください。
デコード結果は以下の通りです。
ヘッダー:
issの値が正しく設定されています。name、email、およびemail_verifiedといった追加クレームが含まれています。
まとめ
このチュートリアルでは、Authlete API を使用して OpenID Connect プロバイダーとして動作する認可サーバーをシミュレートし、認可コードフローを用いて ID トークンを発行する方法を学びました。以下の重要なステップを完了しました。- Authlete API を使用して認可コードフローを認可サーバー (OIDC アイデンティティプロバイダー) に実装する方法
- Authlete 管理コンソールで発行者識別子や追加クレームを設定し、それらを ID トークンからデコードする方法
次のステップ
以下の機能を試し、Authlete をさらに深く理解しましょう。/auth/authorization/failAPI (参考: “fail” API を用いたエラーレスポンスの生成)/auth/userinfoAPI (参照: Access token verification in Userinfo API)- トークン管理 API (参照: ユーザーがクライアントに付与した認可の取得・変更・取り消し)
- 認可サーバーの実装 (参照: Authorization Server Implementation - Getting Started)
- 公開鍵暗号を使用した ID トークンの署名 (参照: ID トークンの署名鍵の変更)