Понимание рефреш-токенов, аксесс-токенов и ID-токенов в протоколе OIDC

はじめに#

OpenID Connect Protocol、通称 OIDC は、アイデンティティ管理の基本的なフレームワークを提供する広く採用された標準となっています。これは、よく知られた OAuth 2.0 プロトコルの上に構築された認証レイヤーです。 OAuth 2.0 はリソースの承認に過ぎませんが、OIDC は新たに導入された ID トークンを用いてクライアント認証を標準化し、強化するプロトコルです。

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

Logtoは、我々の包括的な Customer Identity and Access Management (CIAM) ソリューションは OIDC プロトコルの上に構築されています。私たちのコミュニティでは、ユーザーから最も頻繁に寄せられる質問の1つは次の通りです :

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

そこで、この記事ではOIDCトークンのキーアスペクトに焦点を当てつつ、Logtoが開発者の経験をどのように向上させるかを明らかにします。

実践的なシナリオから始めましょう#

一般的なクライアント-サーバーアプリケーションに取り組んでいると想像してください。そして、それらはRESTful APIを通じて互いに通信します。あなたのAPIのほとんどをプライベートに保ちたいと思います。つまり、許可されたクライアントだけがアクセスできるようにします。それから最初の質問が思い浮かぶかもしれません :

APIを保護するためにどのタイプのトークンが必要ですか？#

素早い答えは：アクセストークンです。

OIDCでは、各保護されたAPIはリソースとして扱われます。アクセストークンは、クライアントがAPIリソースをリクエストする際にサーバに送信する、リクエストヘッダー経由で通常、非常にクレデンシャルです。サーバーサイドでは、リクエストが入ったときに、そのリクエストが有効なアクセストークンを持っているかどうかを検証するだけでよいです。

ただし、次のように思考するかもしれません：クライアントアプリケーションが成功したログイン後に有効なアクセストークンを持つことができて、そのアクセストークンを使用してサーバAPIをリクエストすることが可能であれば、それだけで十分ではないでしょうか？ リフレッシュトークンと ID トークンをなぜ必要とするのですか？

確かに、それは適切な質問で、順を追って説明してみましょう。

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

アクセストークンは最低限の要件を満たすことでシステムを機能させるのにはテクニカルには十分ですが、セキュリティ上の懸念からアクセストークンの有効期限は通常非常に短い（典型的には1時間）です。したがって、私たちがアクセストークンだけを持っていると想像すると、エンドユーザーはアクセストークンが期限切れになるたびに再認証を行わなければならないでしょう。モダンなシングルページウェブアプリケーション、特にモバイルアプリケーションでは、頻繁にログアウトするというのは、ユーザーのセキュリティを保護しようとする私たちだけでなく、非常につらいユーザー体験です。

したがって、私たちはトークンのセキュリティとユーザーの利便性のバランスが必要です。そのためにOIDCはリフレッシュトークンを導入しています。

リフレッシュトークンはなぜ長い寿命を持つことができるのでしょうか？#

アクセストークンはAPIリソースにアクセスするために使用されるため、その短い寿命は漏洩や侵害のリスクを軽減します。一方、リフレッシュトークンは新しいアクセストークンと交換するためだけに使用されるため、アクセストークンと同じ頻度で使用されないため、露出のリスクが減少します。そのため、リフレッシュトークンには長い有効期間が許可されています。

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

リフレッシュトークンもクライアントサイドに保存されるため、それらが侵害されないことを確認することは特に困難で、特にシングルページウェブアプリケーション（SPA）のようなパブリッククライアントにとっては挑戦的です。

Logtoでは、リフレッシュトークンはデフォルトで自動的に回転メカニズムを持っており、これは認証サーバーが新しいリフレッシュトークンを発行するという意味で、以下の基準が満たされたら新しいリフレッシュトークンが発行されます :

• シングルページアプリケーション: これらのアプリは非送信制約クライアントとして認識され、リフレッシュトークンの回転を必須とします。リフレッシュトークンの有効期限（TTL）は指定できません。
• ネイティヴアプリと伝統的なウェブアプリ: リフレッシュトークンの回転が本質的に有効化され、そのTTLの70％に達したら自動的に更新されます。詳しくはこちら

一方、管理コンソールのアプリケーション詳細ページでリフレッシュトークンの回転を無効にするオプションはまだ持っていますが、この保護措置を維持することを強くお勧めします。

IDトークンの本質#

IDトークン はクライアントがサーバにリクエストを送らずに基本的なユーザ情報を取得することを可能にします。

IDトークンは、ユーザー名、メール、アバター画像などのユーザークレームを含む JSON Web Token (JWT) です。これは認証サーバーによって署名され、クライアントはそれをオフラインで検証し、デコードすることができます。これは、特に現代的なシングルページウェブアプリやモバイルアプリにとって非常に便利で、クライアントはIDトークンをキャッシュしてユーザーの認証状態を判断し、全体のパフォーマンスとユーザー体験を大幅に向上させるのに役立ちます。

また、IDトークンは保護されたリソースへのアクセスを許可するためには使用されず、その役割はアクセストークンによって果たされることも重要になります。

Logtoでは、私たちはまた、私たちのSDKでIDトークンを使用してクライアント側での認証状態を判断します。例えば、私たちは JS SDKsで、次のようにすることができます :

しかし、上述のように、クライアントSDKの isAuthenticated フラグはクライアントがキャッシュした状態だけです。リアルタイムの認証状態は、サーバがリフレッシュとアクセストークンを検証することによって決定されなければなりません。

また、私たちは SDK で getUserClaims() 関数を提供して、IDトークンのデコードとユーザークレームの取得を支援します。ただし、キャッシュされた状態はユーザーが再度サインインするまで更新されません。リアルタイムのユーザー情報をOIDCサーバーから取得する場合は、代わりに fetchUserInfo() を使用してください。

Logtoのメリットと機能#

LogtoはOIDCプロトコルに厳密に従いながら、開発者やビジネスに追加の機能とメリットを提供します :

1. 便利なSDKs: Logto SDKsはあなたのためにトークン管理を自動化します。あなた自身でリフレッシュトークンやアクセストークンを手動で保存する必要はありません。毎回 getAccessToken() を呼び出すだけで、SDKは常に保存されたアクセストークンの再利用を試み、または期限が切れていれば自動的に更新します。
2. リフレッシュトークン回転: Logtoは、あなたのリフレッシュトークンが消費された後も常に新しいトークンを生成するリフレッシュトークン回転の仕組みを徹底的に強化します。これにより、漏洩や侵害のリスクが軽減されます。しかし、管理コンソールでそれを無効にすることが可能ですが、それを維持することを強くお勧めします。
3. 最適な性能: IDトークンの助けを借りて、サーバーにリクエストを送らずに基本的なユーザー情報を常に取得することができます。Logto SDKsが提供する isAuthenticated ステータスと getIdTokenClaims() 関数を活用して、クライアント側でユーザーの認証ステータスを確認し、ユーザーの請求をデコードします。
4. セキュリティの向上: Logtoは、クライアントと認証サーバー間の安全な接続をHTTPSとTLSを使用して強制します。これにより、あなたのトークンが非許可の第三者による盗難から保護され、システムのセキュリティが保証されます。

結論#

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

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

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

Logtoを選択することで、開発者やビジネスはOIDCの機能の全能力を開放し、ユーザーデータを保護し、シームレスなユーザー体験を提供する堅牢で安全な認証システムを統合することができます。