oauth 2.0oidc

不透明トークン (Opaque token) とは？

不透明トークン (Opaque token) はクライアントにとって意味のないランダムでユニークな文字列であり、サーバーのデータベースで認可データを検索するための参照キーとして機能します。

不透明トークン (Opaque token) とは？

不透明トークンは、その予測不可能性とセキュリティを確保するために通常暗号的に安全な疑似乱数生成器 (Cryptographically Secure Pseudorandom Number Generator) を使用して生成され、その形式は発行者 (issuer) によって決定されます。

以下は不透明トークンの例です：

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

JWT (JSON Web Token) と不透明トークンの違いは何ですか？

主な違いは、これらのトークンが認可情報を処理および検証する方法にあります：

不透明トークンはそれ自体に情報を含まないランダムな文字列です。サーバーはこのトークンに関連付けられた認可データを取得するためにバックエンドデータベースを照会する必要があります。これにより、不透明トークンは完全に認可サーバー (authorization server) に依存して検証および解釈されます。

JWT は必要な情報をすべて自分自身に含む自己完結型のトークンです。

以下は JWT の例で、base64 エンコードされた文字列です：

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

そして、ドットで区切られた3つの部分を含みます：

ヘッダー - トークンの種類と署名に使用されるアルゴリズムに関する情報を含みます。例：{"alg": "HS256", "typ": "JWT"}。
ペイロード - クレーム (claim) を含みます。ユーザーや認可に関する情報、例えばユーザーID、有効期限、スコープ (scope) などです。エンコードされていますが暗号化されていないため、誰でもクレームを見ることができます。
署名 - ヘッダー、ペイロード、および指定されたアルゴリズムを使用して生成された秘密鍵を組み合わせて生成されます。この署名はトークンの整合性を検証し、改ざんされていないことを確認するために使用されます。

この構造により、JWT はデータベースを照会せずに検証および使用することができます。

JWT に関する詳細情報については、 JSON Web Token (JWT) を参照してください。

また、 Opaque token vs JWT をチェックして、これらの違いについてさらに詳しく学んでください。

不透明トークンをどのように検証するか

単純なシステムでは、不透明トークンの検証は通常サーバーによって直接処理され、不透明トークンをキーとして使用して関連する認可情報を取得するためにデータベースを照会します。

OAuth 2.0 を導入するマルチパーティシステムでは、複数のリソースサーバー (resource server) が同じ不透明トークンを検証する必要がある場合があります。OAuth 2.0 はこの検証のために標準化されたトークンインスペクション (token introspection) メカニズムを提供します：

トークンインスペクションに関する詳細情報については、トークンインスペクション (Token introspection) を参照してください。

OIDC で不透明トークンはどのように使用されるか？

OIDC ( OpenID Connect (OIDC) ) のコンテキストでは、不透明トークンは異なるシナリオで特定の目的を果たします：

ユーザープロファイルの取得

デフォルトでは、クライアントがリソースを指定せずにアクセストークンを要求し、openid スコープを含めると、認可サーバーは不透明なアクセストークンを発行します。このトークンは主に OIDC /oidc/userinfo エンドポイントからユーザープロファイル情報を取得するために使用されます (参照： Userinfo エンドポイント (Userinfo endpoint) )。

リフレッシュトークンの交換

リフレッシュトークン (refresh token) は通常、不透明トークンとして発行されます。これはクライアントと認可サーバーの間でのみ交換されます。現在のアクセストークンが期限切れになると、クライアントは不透明なリフレッシュトークンを使用して、ユーザーを再認証することなく新しいアクセストークンを取得できます。

不透明トークンの利点と欠点は何ですか？

利点

セキュリティ: 不透明トークンはリフレッシュトークンのような機密データを扱うのに最適です。内容が完全にランダムで意味がないため、誰かがトークンを傍受しても有用な情報を抽出することはできません。これにより、銀行取引や機密ユーザーデータの処理など、高セキュリティのシナリオで特に価値があります。
取り消し可能性: サーバーはいつでも不透明トークンを即座に無効にすることができます。これはユーザーアクセスを迅速に削除する必要がある場合に特に便利です。有効期限が切れるまで有効な JWT とは異なり、不透明トークンは即座に取り消すことができます (参照： JWT の制限 )。
サイズ: 不透明トークンは通常、JWT よりもはるかに短いです。この小さいサイズにより、ネットワーク帯域幅の使用量とストレージ要件が削減されます。特にモバイルアプリケーションや IoT デバイスなど、頻繁にトークンを送信するシステムでは、この利点が顕著になります。
シンプルさ: 不透明トークンの実装は簡単です。ランダムな文字列を生成し、それに関連付けられたデータと一緒に保存します。JWT のように複雑な暗号化や署名検証を処理する必要はありません。このシンプルさにより、内部システムの認証に最適です。

欠点

ステートフル: 不透明トークンはすべてサーバー側に保存する必要があります。これにより、トークンデータを複数のサーバー間で同期する必要があるため、分散システムでは追加の複雑さが生じます。たとえば、複数の認証サーバーがある場合、トークンを適切に検証するために、すべてが同じトークンデータベースまたはキャッシュシステムにアクセスする必要があります。
パフォーマンス: トークンの検証には常にデータベースの照会または API 呼び出しが必要です。高トラフィックシステムでは、これらの追加のデータベースクエリがパフォーマンスのボトルネックを引き起こす可能性があります。たとえば、システムが毎秒数千のリクエストを処理し、それぞれがトークンの検証を必要とする場合、追加のデータベース負荷が重要になります。
相互運用性: 異なるシステムが不透明トークンを異なる方法で実装する可能性があります。これにより、サードパーティサービスや異なる認可サーバーと連携する際に統合の課題が生じる可能性があります。OAuth 2.0 トークンインスペクションのような標準が役立ちますが、システムが異なるトークン形式や検証方法を使用する場合、互換性の問題に直面する可能性があります。