日本語
OpenID Connect (OIDC) プロトコルにおけるアクセストークン、リフレッシュトークン、および ID トークンの理解
OpenID Connect (OIDC) プロトコルは、アイデンティティ管理のための広く採用された標準として登場しました。しかし、これらのトークンの役割と属性を本当に理解していますか？
Charles
Developer
Developer
OpenID Connect (OIDC) プロトコルは、アイデンティティ管理のための広く採用された標準として登場しました。しかし、これらのトークンの役割と属性を本当に理解していますか？
OpenID Connect プロトコル、OIDC とも呼ばれるものは、アイデンティティ管理のための基本的なフレームワークを提供するための広く採用された標準となっています。 これは、有名な OAuth 2.0 プロトコル 上に構築された認証レイヤーです。OAuth 2.0 がリソースの認可のためのものであるのに対し、OIDC はクライアント認証を標準化し強化するためのプロトコルであり、新たに導入された ID トークンの助けを借りています。
えっ... OAuth 時代にアクセストークンとリフレッシュトークンを聞いたことがあるかもしれませんが、OIDC に新しい概念が登場しましたか？これらのトークンの違いを本当に理解していますか？
実際のシナリオで始めましょう。
クライアント・サーバーアプリケーションを開発していると想像してみてください。これらは RESTful API を通じてお互いに通信します。ほとんどの API を非公開に保ち、許可されたクライアントのみがアクセスできるようにしたいとします。クライアントを認証し、サーバーへの API リクエストを許可するためのメカニズムが必要です。
理想的には、RESTful API はステートレスであるべきです。つまり、サーバーはクライアントセッション情報を保存してはなりません。有効なリクエストが来たら、サーバーはリクエストされたデータを応答するだけにすべきです。ここでトークンが役立ちます。それでは、このような場合にどのタイプのトークンを使用すべきでしょうか？
OAuth 2.0 と OIDC では、保護された各 API はリソースとして扱われます。アクセストークンは、クライアントが API リソースを要求する際にサーバーに送信するトークンであり、通常リクエストヘッダーを介して JWT 形式で送信されます。
サーバー側では、リクエストが到着するたびに、受信リクエストが有効なアクセストークンを持っているかどうかを検証するだけです。検証プロセスには通常、JWT トークンのデコード、署名と期限の検証、および必要な権限があるかを確保するスコープクレームの確認が含まれます。
しかし、疑問に思うかもしれません：クライアントアプリケーションがログイン成功後に有効なアクセストークンを持っている場合、アクセストークンを使用してサーバー API にリクエストを送信できるのではないでしょうか？他のトークンが必要な理由は何ですか？
確かに有効な質問です。ステップバイステップで説明しましょう。
技術的にはアクセストークンはシステムを動作させるための最小要件を満たしますが、セキュリティ上の懸念からアクセストークンの有効期限は通常非常に短い（通常は 1 時間）です。したがって、アクセストークンしかない場合、エンドユーザーはアクセストークンが期限切れになるたびに再認証する必要があります。現代のシングルページウェブアプリケーション（SPA）や特にモバイルアプリケーションでは、頻繁にログアウトするのは非常に不便なユーザー体験です。これはユーザーのセキュリティを保護しようとしているに過ぎませんが。
そのため、トークンのセキュリティとユーザーの利便性のバランスが必要です。それがリフレッシュトークンが導入された理由です。
アクセストークンは API リソースへのアクセスに使用され、その短期間の性質は漏洩や不正使用のリスクを軽減する助けとなります。他方で、リフレッシュトークンは新しいアクセストークンの取得にのみ使用されるため、アクセストークンほど頻繁に使用されず、露出のリスクが低下します。その結果、長期間の有効性が許容されると考えられています。
リフレッシュトークンもクライアント側に保存されるため、特にシングルページウェブアプリケーション（SPA）やモバイルアプリといったパブリッククライアントの非侵害を保証することは難しいです。
Logto では、リフレッシュトークンに自動ローテーションメカニズムがデフォルトで有効になっており、次の場合に新しいリフレッシュトークンを発行します：
管理コンソールのアプリケーション詳細ページでリフレッシュトークンのローテーションを無効にするオプションもありますが、この防護措置を維持することを強く推奨します。
ID トークンは、認証されたユーザーに関するアイデンティティ情報を提供する OIDC のユニークな機能です。
アクセストークンが保護されたリソースへのアクセスに使用され、リフレッシュトークンが新しいアクセストークンの取得に使用されるのに対し、ID トークンは通常クライアント側でユーザー情報をキャッシュするために使用され、ユーザーデータのために認可サーバーに追加のリクエストを行う必要が減少します。ほとんどの場合、ID トークンを持っていることは、ユーザーが認証されていることと同等であると言っても過言ではありません。
OIDC プロトコルでは、リフレッシュトークン、アクセストークン、および ID トークンが連携して、セキュアでシームレスなユーザー認証を提供します。
これらのトークンの役割と重要性を理解することは、アプリケーションで OIDC 認証を実装する開発者にとって重要です。