跳至主要內容

不透明權杖 (Opaque token)

在驗證 (Authentication) 過程中，如果未指定資源，Logto 將簽發不透明存取權杖 (Opaque token) 而非 JWT。不透明權杖是一個隨機字串，比 JWT 短得多：

{
  "access_token": "some-random-string", // 不透明權杖 (Opaque token)
  "expires_in": 3600,
  "id_token": "eyJhbGc...aBc", // JWT
  "scope": "openid profile email",
  "token_type": "Bearer"
}

不透明權杖可用於呼叫 userinfo endpoint 並存取需要驗證的受保護資源。由於它不是 JWT，資源伺服器如何驗證它？

Logto 提供了一個 introspection endpoint 可用於驗證不透明權杖。預設情況下，introspection endpoint 是 /oidc/token/introspection，並接受 POST 請求。以下參數是必需的：

  • token：要驗證的不透明權杖

此 endpoint 也需要客戶端驗證。你可以使用以下方法之一：

  • HTTP Basic 驗證：使用 Authorization 標頭，值為 Basic <base64-encoded-credentials>。憑證必須是客戶端 ID 和客戶端密鑰，以冒號（:）分隔並進行 base64 編碼。
  • HTTP POST 驗證：使用 client_id 和 client_secret 參數：
    • client_id：請求權杖的應用程式的客戶端 ID
    • client_secret：請求權杖的應用程式的客戶端密鑰

客戶端 ID（應用程式 ID）和客戶端密鑰（應用程式密鑰）可以是 Logto 中任何「傳統網頁」或「機器對機器」應用程式的應用程式憑證。如果憑證無效，introspection endpoint 將返回錯誤。

introspection endpoint 返回一個包含權杖宣告的 JSON 物件：

{
  "active": true, // 權杖是否有效
  "sub": "1234567890" // 權杖的主體 (Subject)（使用者 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。