ข้ามไปยังเนื้อหาหลัก

โทเค็นทึบ (Opaque token)

ระหว่างกระบวนการการยืนยันตัวตน (Authentication) หากไม่ได้ระบุ resource Logto จะออกโทเค็นการเข้าถึงแบบทึบ (opaque access token) แทน JWT โดยโทเค็นทึบจะเป็นสตริงสุ่มและสั้นกว่า JWT มาก:

{
  "access_token": "some-random-string", // โทเค็นทึบ
  "expires_in": 3600,
  "id_token": "eyJhbGc...aBc", // JWT
  "scope": "openid profile email",
  "token_type": "Bearer"
}

โทเค็นทึบสามารถใช้เรียก userinfo endpoint และเข้าถึงทรัพยากรที่ต้องการการยืนยันตัวตน (Authentication) ได้ เนื่องจากมันไม่ใช่ JWT แล้ว resource server จะตรวจสอบความถูกต้องได้อย่างไร?

Logto มี introspection endpoint สำหรับตรวจสอบโทเค็นทึบ โดยดีฟอลต์ endpoint นี้คือ /oidc/token/introspection และรับ POST requests โดยต้องมีพารามิเตอร์ดังนี้:

  • token: โทเค็นทึบที่ต้องการตรวจสอบ

Endpoint นี้ต้องการการยืนยันตัวตนของ client ด้วย คุณสามารถใช้วิธีใดวิธีหนึ่งต่อไปนี้:

  • HTTP Basic authentication: ใช้ header Authorization ที่มีค่า Basic <base64-encoded-credentials> โดย credentials คือ client ID และ client secret คั่นด้วยเครื่องหมายโคลอน (:) แล้วเข้ารหัส base64
  • HTTP POST authentication: ใช้พารามิเตอร์ client_id และ client_secret:
    • client_id: client ID ของแอปที่ขอโทเค็น
    • client_secret: client secret ของแอปที่ขอโทเค็น

client ID (app ID) และ client secret (app secret) สามารถใช้ข้อมูลรับรองของแอปประเภท "traditional web" หรือ "machine-to-machine" ใด ๆ ใน Logto ได้ หาก credentials ไม่ถูกต้อง introspection endpoint จะส่ง error กลับมา

introspection endpoint จะคืนค่าเป็นอ็อบเจกต์ JSON ที่มีการอ้างสิทธิ์ (Claims) ของโทเค็น:

{
  "active": true, // โทเค็นนี้ใช้ได้หรือไม่
  "sub": "1234567890", // subject ของโทเค็น (user ID)
  "acr": "urn:logto:acr:1fa", // ระดับความมั่นใจในการยืนยันตัวตน (authentication assurance level) เมื่อสำเร็จ
  "amr": ["pwd"], // วิธีการยืนยันตัวตนที่ใช้ใน interaction นี้
  "auth_time": 1787745600 // เวลาที่ผู้ใช้ยืนยันตัวตน (epoch seconds)
}

หากโทเค็นไม่ถูกต้อง ฟิลด์ active จะเป็น false และจะไม่มีการอ้างสิทธิ์อื่น ๆ ดู Step-up authentication สำหรับวิธีตรวจสอบ acr, amr และ auth_time โปรดทราบว่า JWT access token แบบมีโครงสร้างไม่สามารถ introspect ได้ที่ /oidc/token/introspection — ให้ ตรวจสอบ JWT access token ในเครื่องกับ JWKS ของ tenant ของคุณเสมอ

ตัวอย่างที่ไม่เป็นทางการของ introspection request:

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] ด้วย tenant ID ของคุณ

โทเค็นทึบ (Opaque token) กับองค์กร (Organizations)​

โทเค็นทึบสามารถใช้ดึงข้อมูลสมาชิกองค์กรผ่าน userinfo endpoint ได้ เมื่อคุณร้องขอ scope urn:logto:scope:organizations userinfo endpoint จะคืนค่าการอ้างสิทธิ์ที่เกี่ยวข้องกับองค์กรของผู้ใช้ เช่น organizations (organization IDs) และ organization_data

อย่างไรก็ตาม โทเค็นทึบไม่สามารถใช้เป็นโทเค็นองค์กร (Organization token) ได้ โทเค็นองค์กรจะออกในรูปแบบ JWT เสมอ เพราะว่า:

  1. โทเค็นองค์กรมีการอ้างสิทธิ์เฉพาะองค์กร (เช่น organization_id และสิทธิ์ที่กำหนดขอบเขต) ซึ่ง resource server ต้องตรวจสอบ
  2. รูปแบบ JWT ช่วยให้ resource server ตรวจสอบโทเค็นและดึง context ขององค์กรได้โดยไม่ต้องเรียก API เพิ่มเติม

หากต้องการรับโทเค็นองค์กร คุณต้องใช้ refresh token flow หรือ client credentials flow พร้อมพารามิเตอร์ขององค์กร