メインコンテンツまでスキップ

不透明トークン (Opaque token)

認証 (Authentication) プロセス中にリソースが指定されていない場合、Logto は JWT の代わりに不透明トークン (Opaque token) を発行します。不透明トークンはランダムな文字列であり、JWT よりもはるかに短いです：

{
  "access_token": "some-random-string", // 不透明トークン
  "expires_in": 3600,
  "id_token": "eyJhbGc...aBc", // JWT
  "scope": "openid profile email",
  "token_type": "Bearer"
}

不透明トークンは、userinfo エンドポイント を呼び出すためや、認証 (Authentication) を必要とする保護されたリソースにアクセスするために使用できます。JWT ではないため、リソースサーバーはどのようにしてそれを検証できるのでしょうか？

Logto は、不透明トークンを検証するために使用できる introspection エンドポイント を提供しています。デフォルトでは、introspection エンドポイントは /oidc/token/introspection であり、POST リクエストを受け付けます。次のパラメーターが必要です：

  • token: 検証する不透明トークン

このエンドポイントはクライアント認証も必要とします。次のいずれかの方法を使用できます：

  • HTTP Basic 認証: Authorization ヘッダーに Basic <base64-encoded-credentials> の値を使用します。資格情報はクライアント ID とクライアントシークレットをコロン (:) で区切り、base64 エンコードしたものです。
  • HTTP POST 認証: client_id と client_secret パラメーターを使用します：
    • client_id: トークンを要求したアプリケーションのクライアント ID
    • client_secret: トークンを要求したアプリケーションのクライアントシークレット

クライアント ID (アプリ ID) とクライアントシークレット (アプリシークレット) は、Logto の任意の「従来のウェブ」または「マシン間通信」アプリケーションからのアプリ資格情報であることができます。資格情報が無効な場合、introspection エンドポイントはエラーを返します。

introspection エンドポイントは、トークンのクレームを含む JSON オブジェクトを返します：

{
  "active": true, // トークンが有効かどうか
  "sub": "1234567890" // トークンのサブジェクト (ユーザー ID)
}

トークンが無効な場合、active フィールドは false になり、sub フィールドは省略されます。

以下は、introspection リクエストの非規範的な例です：

curl --location \
  --request POST 'https://[tenant-id].logto.app/oidc/token/introspection' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'token=some-random-string' \
  --data-urlencode 'client_id=1234567890' \
  --data-urlencode 'client_secret=1234567890'

[tenant-id] をあなたのテナント ID に置き換えることを忘れないでください。