Skip to main content
このページは Authlete 3.0 用です。2.x についてはこちらのページをご覧ください。

はじめに

このドキュメントは、Authlete APIs を使用して、認可コードフロー をサポートする OpenID Connect (OIDC) アイデンティティプロバイダー (IdP) サーバーを実装する基本的な使用方法を説明するためのチュートリアルです。 このチュートリアルを完了すると、以下を実施できます:
  • 認可サーバーから Authlete へのリクエストをシミュレーションしながら、Authlete API へのリクエストを送信します。
  • 認可リクエストで追加のクレームを含む発行者識別子の値を Authlete 管理コンソールに設定し、それらが ID トークンからデコードされる様子を確認します。

認可コードフローのコンポーネント

Noteこのチュートリアルでは便宜上、OIDC アイデンティティプロバイダーを「認可サーバー」、同リライングパーティを「クライアント」と表記します。
一般的な Authlete の実装では、認可サーバーのミドルウェアが Authlete API へのリクエストの送信およびレスポンスの処理を担当します。このチュートリアルでは、bash/zsh の curl コマンドを使用してこれらのリクエストを直接行います。もちろん、PowerShell や Postman など、別の HTTP クライアントを使用することもできますが、その場合は手順を適宜調整する必要があります。 この OAuth フロー内で各コンポーネントがどのように連携するかを理解するために、各コンポーネントの完全修飾ドメイン名 (FQDN) を以下に示します。認可サーバーとクライアントの FQDN は参考用に作成されたものであり、実際の実装では適切な値に置き換える必要があります
NoteAPI エンドポイントはクラスターごとに異なります。他のクラスターのサービスを使用する場合は、そのクラスターの ISO コードを完全なドメイン名に置き換える必要があります (例: br, eu, jp)。

環境設定

Noteこのセクションの設定は、Authlete API チュートリアル「OAuth 2.0 の基本」に記載されている内容と同じです。このチュートリアルをすでに完了している場合は、このセクションをスキップできます。
Authlete API サービスを作成し、サービスにクライアントを登録する方法については、「API を使ってみる」を参照してください。 サービス ID, サービス アクセストークン, そしてクライアントシークレットの値を書き留めるのを忘れないようにしてください。 すでに他の Authlete チュートリアルを完了している場合、既存のサービスを再利用できます。そうでない場合は、以下の値を使用してサービスを作成し、他のすべてのフィールドはデフォルトのままにしてください。 以下の値を使用してクライアントを作成し、他のすべてのフィールドはデフォルトのままにしてください。 クライアントを作成したら、クライアント設定 > エンドポイント > 基本設定に移動します。リダイレクト 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_typescope などの他のパラメータの値が、クライアントに対して許可されているかどうか。
その後、scoperesponse_type の値がそれぞれ openidcode であるため、認可サーバーは OIDC 認可コードフローを処理します。 ただし、Authlete アーキテクチャでは、認可サーバーは単に Authlete API によって処理される認可ロジックのプロキシとして機能します。このロジックは /auth/authorization エンドポイントで公開されています。リクエストを受け取ると、Authlete API が認可サーバーに代わって評価プロセスを実行します。 ここから、認可サーバーのリクエストをこの API にシミュレートします。 以下のように curl コマンドを実行してください (メッセージ #5)。前のステップで生成した <サービス ID> (Service ID)、<サービス アクセス トークン> (Service Access Token)、および <クライアント ID> (Client ID) を置き換えて使用します。
成功すると、Authlete は次のようなレスポンスを返します (簡略化のため省略されています) (メッセージ #6)。
このレスポンスの resultMessageactionticket の 3 つのキー/値ペアに注意してください。
  • resultMessage: リクエスト処理の結果を人間が読める形式で提供します(詳細は Authlete の結果コードの解釈 を参照)。openid=true は、リクエストが OIDC プロトコルに従って処理されることを示します。
  • action: 認可サーバーが次に行うべきアクションを示します(詳細は アクションハンドリング を参照)。
  • ticket: 次のステップで別の API にリクエストを行うために必要です(詳細は 2 段階の API 呼び出し を参照)。
Authlete はまた、レスポンス内にサービスおよびクライアント情報を提供します。認可サーバーはこれを使用して、リソースオーナーがクライアントに対してアクセスを許可するかどうかを尋ねます。

ユーザー認証と認証結果の共有確認

リソースオーナーと認可サーバー間の実際のやり取りは、このチュートリアルの範囲外です。通常、認可サーバーは以下のプロセスを実行します:
  • 資格情報 (例: ID/パスワード) を使用してユーザーを認証します。
  • ユーザーのロールや権限を決定します。
  • ユーザーに、認証結果をクライアントと共有するかどうかを確認します。
これらのプロセスは、ステップ #7、#8、#9 に対応します。

認可コードの発行

次に進む前に、認可サーバーが以下の状態にあると仮定します:
  • 認可サーバーがリソースオーナーを認証し、subject パラメータとして Authlete に共有されるリソースオーナーの識別子が testuser01 であることを決定した。
  • 認可サーバーがリソースオーナーの同意を取得した。
認可サーバーは、Authlete の /auth/authorization/issue にリクエストを送信し、認可コードを発行します。このリクエストには、subject/auth/authorization API のレスポンスに含まれる ticket の値が含まれます。 以下の curl コマンドを実行してください (メッセージ #10)。先ほど生成した <Service ID><Service Access Token>、および <Ticket> を置き換えて使用します。
成功すると、Authlete は次のようなレスポンスを返します (ステップ #11)。
このレスポンスの resultMessageactionresponseContent の 3 つのキー/値ペアに注目してください。
  • resultMessage: リクエスト処理の結果を人間が読める形式で提供します(詳細は Authlete の結果コードの解釈 を参照)。
  • action: 認可サーバーが次に行うべきアクションを示します。このレスポンスの値は LOCATION であり、認可サーバーがユーザーエージェントにリダイレクトレスポンスを返すべきことを示しています(詳細は アクションハンドリング を参照)。
  • responseContent: 認可サーバーからのレスポンス内容を示します(詳細は アクションハンドリング を参照)。
認可サーバーは、以下のようなレスポンスをユーザーエージェントに送信します (ステップ #12)。

認可コードの発行に失敗した場合

場合によっては、認可サーバーがリソースオーナーから認可を受けられないことがあります。この場合、クライアントにトークンを発行せず、認可フローが終了したことを通知する必要があります。Authlete の /auth/authorization/fail API は、クライアントに送信されるメッセージおよびレスポンスの転送方法の観点から、この終了プロセスをサポートします。 まとめると、通常の状況では、認可サーバーはユーザー認証と同意の結果に応じて、/auth/authorization/issue または /auth/authorization/fail API のいずれかにリクエストを送信します。

トークンリクエスト

ここでは、ユーザーエージェントが認可サーバーからのリダイレクトレスポンスを受け取ったと仮定します。このリダイレクトレスポンスは以下のようにクライアントに転送されます (ステップ #13)。
クライアントは code パラメータの値を抽出し、それを使用してトークンリクエストを構築し、認可サーバーに送信します。以下はその例です (改行を追加して可読性を向上させています)。https://as.example.com/token は、このチュートリアルにおけるトークンエンドポイント URI です (ステップ #14)。
認可サーバーは、リクエストのパラメータを評価し、クライアントにトークンレスポンスを返すために Authlete API にリクエストを送信します。 ここで、このステップをシミュレートするために Authlete の /auth/token API を使用します。この API はリクエストを評価し、レスポンスを生成します。 以下の curl コマンドを実行してください (ステップ #15)。先ほど生成した <Service ID><Service Access Token><Client ID><Client Secret>、および <Code> を置き換えて使用します。
成功すると、Authlete は次のようなレスポンスを返します (メッセージ #16)。
このレスポンスの resultMessageactionresponseContent の 3 つのキー/値ペアに注目してください。
  • resultMessage: リクエスト処理の結果を人間が読める形式で提供します(詳細は Authlete の結果コードの解釈 を参照)。
  • action: 認可サーバーが次に行うべきアクションを示します。この場合の値は OK であり、認可サーバーがクライアントにトークンレスポンスを返すべきことを示しています(詳細は アクションハンドリング を参照)。
  • responseContent: 認可サーバーからクライアントへのレスポンス内容を示します(詳細は アクションハンドリング を参照)。
認可サーバーは以下のレスポンスをクライアントに送信する必要があります (メッセージ #17)。
クライアントはこのレスポンスを受信すると、必要に応じて ID トークンをデコードします。

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 セクションにデコードされた内容を確認してください。 デコード結果は以下のようになります。 ヘッダー:
ペイロード:
上記の内容には、修正が必要な点がいくつかあります。
  • isshttps://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 パラメータを使用してクレームを追加します。リクエストは以下のように構築されます。
以下のようなレスポンスを受け取るはずです。
認可サーバーは以下のリダイレクトレスポンスをユーザーエージェントに送信する必要があります。その後、ユーザーエージェントは以下のような HTTP GET リクエストをクライアントに送信します。

トークンリクエストの送信

クライアントは以下のようにトークンリクエストを認可サーバーに送信します (改行は可読性向上のため追加されています)。
認可サーバーは、Authlete の /auth/token API を呼び出します。
Authlete は以下のようなレスポンスを返します。
認可サーバーは以下のレスポンスをクライアントに返すことが期待されます (メッセージ #17)。
クライアントがこのレスポンスを受信した後、再び Online JWT Verifier を使用してトークンをデコードしてみましょう。 上記リンクを開き、レスポンス内の id_token の値を Step 1 のテキストエリアに貼り付けます。このチュートリアルでは ID トークンの値として eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0 を使用します。 その後、Step 3Just Decode JWT ボタンをクリックし、Parsed JWT セクションでデコードされた内容を確認してください。 デコード結果は以下の通りです。 ヘッダー:
ペイロード:
これにより、以下の点が確認できます。
  • iss の値が正しく設定されています。
  • nameemail、および email_verified といった追加クレームが含まれています。

まとめ

このチュートリアルでは、Authlete API を使用して OpenID Connect プロバイダーとして動作する認可サーバーをシミュレートし、認可コードフローを用いて ID トークンを発行する方法を学びました。以下の重要なステップを完了しました。
  • Authlete API を使用して認可コードフローを認可サーバー (OIDC アイデンティティプロバイダー) に実装する方法
  • Authlete 管理コンソールで発行者識別子や追加クレームを設定し、それらを ID トークンからデコードする方法
このウォークスルーでは一部のプロセスを簡略化しましたが、Authlete をバックエンドサービスとして利用することで、独自のインフラストラクチャ上でホストされる認可サーバーがどのように動作するかを深く理解できたはずです。独自の認可サーバーを構築する場合、複雑なロジックやコード、シークレットの安全な取り扱いに細心の注意を払う必要がありますが、Authlete API を利用することで、これらの実装を大幅に簡素化できます。

次のステップ

以下の機能を試し、Authlete をさらに深く理解しましょう。