OpenID Connect 設定の探究: 主要なフィールドとその用途

今日のデジタル世界では、認証はウェブサイトやアプリケーションのセキュリティを確保するための中心的な要素となっています。OAuth 2.0 プロトコルの上に構築された認証レイヤーである OpenID Connect (OIDC) は、標準化された簡単な方法でアイデンティティを認証します。

しかし、OIDC を適切に統合するのは、特に初心者にとっては難しいことがあります。良い出発点として、多くの場合、OIDC 設定ファイルがあります。通常は {authServerUrl}/.well-known/openid-configuration URL で見つかり、OIDC サービスを実装するために必要なすべての詳細を含んでいます。

このガイドは、この設定内の主要なフィールドを明確にし、開発者がその重要性と実際の用途を理解し、OIDC をプロジェクトにより良く統合できるようにすることを目的としています。

OIDC 設定フィールドの分析#

OIDC 設定は以下のような JSON ファイルです:

次に、一部の重要なフィールドを詳しく見ていきます。

authorization_endpoint#

OIDC サービスを統合する際、最初のステップは通常、アプリケーション内でユーザーログインリクエストを処理することです。このプロセスにはユーザーを認証のためにログインページへ誘導する、認可サーバーの authorization_endpoint にユーザーをリダイレクトすることが含まれます。このエンドポイントは認可リクエストが送信されるサーバーアドレスであり、ユーザーをログインページに導くためのものです。

authorization_endpoint にリクエストするときは、認可ごとに追加のクエリパラメータを設定する必要があります:

• response_type: 返される認可のタイプを指定します。これには通常、(認可コードフローの)"code"、(インプリシットフローの)"token"、および (ハイブリッドフロー用の)"id_token token" や "code id_token" が含まれ、OIDC 設定の response_types_supported フィールドに記載されています。
• client_id: アプリケーションが登録されたときに認可サーバーから割り当てられる一意の識別子です。この ID は、リクエストを開始するクライアントアプリケーションを認可サーバーが識別するために使用されます。
• scope: リクエストされたアクセス範囲を定義し、アクセス可能なリソースやユーザー情報を指定します。一般的なスコープには「openid」(必須)、「profile」、「email」などがあります。サポートされているスコープは OIDC 設定の scopes_supported フィールドに記載されており、異なるスコープはスペースで区切る必要があります。
• redirect_uri: ログインまたは認可後に、認可サーバーがユーザーをアプリケーションによって提供される URI にリダイレクトします。この URI は、アプリケーション登録時に提供された URI と厳密に一致する必要があります。
• state: クロスサイトリクエストフォージェリ攻撃からクライアントを保護するためにランダムに生成された文字列です。リクエストとコールバックの間でこの state の一貫性を保つことで、セキュリティを確保します。

これらのパラメータを使用することで、開発者は OIDC 認可リクエストの挙動を正確に制御し、セキュリティを確保しながらアプリケーションのニーズに合ったものにすることができます。

authorization_endpoint にリクエストを完了し認証を通過すると、ユーザーは指定された redirect_uri にリダイレクトされ、そこで非常に重要なクエリパラメータ—code が付加されます。この認可コードは、ユーザーが認証し、認可サーバーで情報へのアクセスをアプリに許可した結果、認可サーバーから提供されるものです。

token_endpoint#

token_endpoint は、認可サーバーが前述の認可コードをアクセスおよびリフレッシュトークンと交換するために使用するサーバーエンドポイントです。OAuth 2.0 認可コードフローにおいてこのステップは極めて重要であり、ここで得られた認可コードを実際のアクセス トークンに変換し、アプリがユーザーの保護されたリソースにアクセスできるようにします。

次のように、認可コードをアクセス トークンに交換する方法を実装します (この例では client_secret_post 認証方法を使用しています。サポートされている他の認証方法については、後の

フィールドの分析を参照してください):

このコードでは、まず POST メソッドを使用して token_endpoint にリクエストを送信します。コンテンツタイプは application/x-www-form-urlencoded に設定されており、多くの認可サーバーではこれが必要です。リクエストボディに含まれるパラメータは次のとおりです:

• code: 認可サーバーから取得した認可コードで、ユーザーが認可を完了した後、redirectUri 経由で返されます。
• redirect_uri: 認可コードを取得するために使用された同じリダイレクト URI であり、リクエストの正当性を検証するために使用されます。
• client_id: リクエストを行っているアプリケーションのクライアント識別子です。
• client_secret: アプリケーションのクライアントシークレットであり、アプリケーションのアイデンティティを確認するために使用されます。
• grant_type: 認可のタイプを指定し、ここではアクセス トークンが認可コードを介して取得されることを示す "authorization_code" が使用されています。

この関数は非同期に実行され、アプリケーションがユーザーデータをリクエストしたり他の操作を行う際に使用できるアクセス トークンを含む JSON オブジェクトが返されます。

userinfo_endpoint#

userinfo_endpoint は、認可サーバーが認証されたユーザーに関する詳細情報を取得するために使用するサーバーエンドポイントです。ユーザーが token_endpoint を介して認可に成功し、アクセス トークンを取得した後、アプリケーションはこのエンドポイントにリクエストを送信し、ユーザーのプロフィール情報 (例: ユーザー名やメールアドレス) を取得することができます。取得される具体的な情報は、認証リクエストでユーザーによって指定された scope によります。

この関数では、まず GET メソッドを使用して userinfo_endpoint にリクエストを送信し、リクエストヘッダーに token_type と accessToken で構成される Authorization フィールドを含めます。これは OAuth 2.0 仕様に従った標準的な操作であり、ユーザー情報を安全に取得することを保証します。また、アクセス トークンを介してアクセスされるユーザー情報の範囲は、認可開始時に採用された scope パラメータ値に完全に依存します。例えば、email スコープが使用された場合、レスポンスにはユーザーのメールアドレスが含まれます。

issuer & jwks_uri#

issuer は認可サーバーの URL を識別し、jwks_uri は JWT 署名を検証するために使用される公開鍵のセットである JSON Web Key Set (JWKS) の URI を提供します。JWT の issuer および署名の検証はトークンのセキュリティを確保するための基本的なステップですが、実際のシナリオでは、検証プロセスには通常、トークンの有効期限、対象、認可範囲、その他の重要なフィールドを確認することも含まれます。

以下のコードは、issuer と jwks_uri を組み合わせて JWT を検証する方法を示しています:

scopes_supported & claims_supported#

claims_supported と scopes_supported フィールドは、認可サーバーがサポートするユーザー属性 (クレーム) とアクセス範囲 (スコープ) を宣言します。これにより、クライアントは認可サーバーがサポートするユーザー属性およびアクセス範囲を理解し、認可リクエストの構築およびレスポンスの解析を効果的に行えるようになります。

認可リクエストを構築する際、クライアントはアプリケーションのニーズに応じて必要な scope を指定できます。scope はクライアントがアクセスを要求するリソースおよび操作を定義し、例えば openid、email、profile などがあります。

重要なのは、各認可リクエストでアクセス可能な特定のクレームは、認証リクエストの開始時に指定されたスコープの値に基づいて異なることです。例えば、email スコープはユーザーのメールアドレスへのアクセスを許可し、phone スコープはユーザーの電話番号へのアクセスを提供します。したがって、クライアントは認可リクエストを作成する際に関連するスコープを慎重に選択し、アプリケーションのニーズに一致するユーザー属性を取得できるようにする必要があります:

token_endpoint_auth_methods_supported

#

フィールドは、トークンエンドポイントでサポートされている認証方法を示します。これらの方法は、認可コードをアクセス トークンと交換する際にクライアントが認可サーバーに対して認証するために使用されます。

トークンエンドポイントを使用して認証する場合、一般的な認証方法には client_secret_post、client_secret_basic、および client_secret_jwt があります。

• client_secret_post: クライアントは、クライアントIDとクライアントシークレットを使用してフォームエンコードされたボディを作成し、これをリクエストボディの一部として送信します。この方法の例は、前述の token_endpoint セクションで既に見ています。

• client_secret_basic: クライアントはクライアントIDとクライアントシークレットを使用して基本認証ヘッダーを構築し、これをリクエストヘッダーに追加します。

• client_secret_jwt: クライアントは JWT (JSON Web Token) をクライアントアサーションとして使用し、認証します。この JWT にはクライアントIDおよび追加メタデータが含まれており、クライアントシークレットを使用して署名されています。リクエストを受信した後、認可サーバーは JWT の署名を検証してクライアントのアイデンティティを確認します。

実際のアプリケーションでは、クライアントは認可サーバーによってサポートされている方法に基づいて適切な認証方法を選択し、認証情報が正しくリクエストに追加され、認可コードを安全にアクセス トークンに交換できるようにする必要があります。

まとめ#

これまでに、OIDC 設定の主要なフィールドについて、その目的と用途に焦点を当てて探求してきました。これらの詳細を理解することで、OpenID Connect についての理解が深まり、プロジェクトにより効果的に統合して活用できるようになります。この知識をもとに、OIDC の全潜在力を活用して、より安全で効率的なユーザー認証ソリューションを実現できるでしょう。

OIDC を基盤にした認証サービスとして Logto は、多様な言語の SDK スイートと数多くの統合チュートリアルを提供しており、数分でアプリケーションに OAuth / OIDC ログインをシームレスに統合することができます。信頼性が高く使いやすい OIDC サービスをお探しの方は、Logto をぜひお試しください！