OpenID Connect (OIDC) プロトコルにおけるアクセストークン、リフレッシュトークン、および ID トークンの理解

OIDC、OAuth 2.0、トークン#

OpenID Connect プロトコル、OIDC とも呼ばれるものは、アイデンティティ管理のための基本的なフレームワークを提供するための広く採用された標準となっています。 これは、有名な OAuth 2.0 プロトコル 上に構築された認証レイヤーです。OAuth 2.0 がリソースの認可のためのものであるのに対し、OIDC はクライアント認証を標準化し強化するためのプロトコルであり、新たに導入された ID トークンの助けを借りています。

えっ... OAuth 時代にアクセストークンとリフレッシュトークンを聞いたことがあるかもしれませんが、OIDC に新しい概念が登場しましたか？これらのトークンの違いを本当に理解していますか？

OIDC でのアクセストークン、リフレッシュトークン、ID トークンとは何ですか？#

実際のシナリオで始めましょう。

クライアント・サーバーアプリケーションを開発していると想像してみてください。これらは RESTful API を通じてお互いに通信します。ほとんどの API を非公開に保ち、許可されたクライアントのみがアクセスできるようにしたいとします。クライアントを認証し、サーバーへの API リクエストを許可するためのメカニズムが必要です。

理想的には、RESTful API はステートレスであるべきです。つまり、サーバーはクライアントセッション情報を保存してはなりません。有効なリクエストが来たら、サーバーはリクエストされたデータを応答するだけにすべきです。ここでトークンが役立ちます。それでは、このような場合にどのタイプのトークンを使用すべきでしょうか？

アクセストークンは API を保護するために使用されます#

OAuth 2.0 と OIDC では、保護された各 API はリソースとして扱われます。アクセストークンは、クライアントが API リソースを要求する際にサーバーに送信するトークンであり、通常リクエストヘッダーを介して JWT 形式で送信されます。

サーバー側では、リクエストが到着するたびに、受信リクエストが有効なアクセストークンを持っているかどうかを検証するだけです。検証プロセスには通常、JWT トークンのデコード、署名と期限の検証、および必要な権限があるかを確保するスコープクレームの確認が含まれます。

しかし、疑問に思うかもしれません：クライアントアプリケーションがログイン成功後に有効なアクセストークンを持っている場合、アクセストークンを使用してサーバー API にリクエストを送信できるのではないでしょうか？他のトークンが必要な理由は何ですか？

確かに有効な質問です。ステップバイステップで説明しましょう。

なぜリフレッシュトークンが必要なのでしょうか？#

技術的にはアクセストークンはシステムを動作させるための最小要件を満たしますが、セキュリティ上の懸念からアクセストークンの有効期限は通常非常に短い（通常は 1 時間）です。したがって、アクセストークンしかない場合、エンドユーザーはアクセストークンが期限切れになるたびに再認証する必要があります。現代のシングルページウェブアプリケーション（SPA）や特にモバイルアプリケーションでは、頻繁にログアウトするのは非常に不便なユーザー体験です。これはユーザーのセキュリティを保護しようとしているに過ぎませんが。

そのため、トークンのセキュリティとユーザーの利便性のバランスが必要です。それがリフレッシュトークンが導入された理由です。

リフレッシュトークンはなぜ長期間有効なのでしょうか？#

アクセストークンは API リソースへのアクセスに使用され、その短期間の性質は漏洩や不正使用のリスクを軽減する助けとなります。他方で、リフレッシュトークンは新しいアクセストークンの取得にのみ使用されるため、アクセストークンほど頻繁に使用されず、露出のリスクが低下します。その結果、長期間の有効性が許容されると考えられています。

リフレッシュトークンのセキュリティを確保する#

リフレッシュトークンもクライアント側に保存されるため、特にシングルページウェブアプリケーション（SPA）やモバイルアプリといったパブリッククライアントの非侵害を保証することは難しいです。

Logto では、リフレッシュトークンに自動ローテーションメカニズムがデフォルトで有効になっており、次の場合に新しいリフレッシュトークンを発行します：

• シングルページアプリケーション: 非送信者制約クライアントとして認識され、リフレッシュトークンのローテーションが義務付けられています。リフレッシュトークンの存続時間（TTL）は指定できません。
• ネイティブアプリや従来のウェブアプリ: リフレッシュトークンのローテーションが本質的に有効で、TTL の 70% に達すると自動的に更新されます。 Logto におけるリフレッシュトークンのローテーションについての詳細はこちら

管理コンソールのアプリケーション詳細ページでリフレッシュトークンのローテーションを無効にするオプションもありますが、この防護措置を維持することを強く推奨します。

ID トークンとは何か？なぜそれが重要なのか？#

ID トークンは、認証されたユーザーに関するアイデンティティ情報を提供する OIDC のユニークな機能です。

アクセストークンが保護されたリソースへのアクセスに使用され、リフレッシュトークンが新しいアクセストークンの取得に使用されるのに対し、ID トークンは通常クライアント側でユーザー情報をキャッシュするために使用され、ユーザーデータのために認可サーバーに追加のリクエストを行う必要が減少します。ほとんどの場合、ID トークンを持っていることは、ユーザーが認証されていることと同等であると言っても過言ではありません。

トークンの取り扱いにおけるベストプラクティス#

• HTTPS を使用する: 常に HTTPS を使用して、クライアントと認可サーバー間の通信を保護します。これにより、不正な第三者がトークンを傍受したり盗んだりすることを防ぎます。
• 適切なトークンの有効期限を設定する: アクセストークンは短い存続時間を持つようにして、漏洩のリスクを最小限に抑えます。リフレッシュトークンはより長い有効期間を持たせることができます。
• リフレッシュトークンのローテーションを有効にする: リフレッシュトークンのローテーションを実装して、リフレッシュトークンの漏洩リスクを軽減します。
• 詳細なアクセス制御を使用する: 詳細なスコープを使用して、アクセストークンの権限を制限します。クライアントアプリケーションに必要な権限のみを要求します。絶対に必要でない限り、「すべて」または「管理者」スコープを使用して、ほとんどの権限チェックをバイパスすることは避けてください。

OIDC におけるアクセストークン、リフレッシュトークン、および ID トークンの主な違いのまとめ#

OIDC プロトコルでは、リフレッシュトークン、アクセストークン、および ID トークンが連携して、セキュアでシームレスなユーザー認証を提供します。

• アクセストークンは、保護されたリソースへのアクセスを提供します。
• リフレッシュトークンは、ユーザーの介入なしで新しいアクセストークンを取得します。
• ID トークンは、クライアントでキャッシュされたユーザー情報を提供し、パフォーマンスを向上させます。

これらのトークンの役割と重要性を理解することは、アプリケーションで OIDC 認証を実装する開発者にとって重要です。