การเชื่อมต่อ Backend
AM เปิดเผย public key ผ่าน JWKS และคอนฟิกผ่าน OIDC discovery ซึ่งเป็นโปรโตคอลมาตรฐานที่ไลบรารี JWT ส่วนใหญ่รองรับ
ตรวจสอบโทเคนแบบ local เชื่อถือ claims และอนุญาตคำขอได้ทันที
ขั้นตอนการตรวจสอบโทเคน
Endpoints
| Endpoint | วัตถุประสงค์ |
|---|---|
/.well-known/jwks.json |
กุญแจสาธารณะสำหรับลงลายเซ็น |
/.well-known/openid-configuration |
เอกสาร OIDC discovery |
/oauth2/introspect |
ตรวจสอบ refresh token |
JWKS
ดึง public key เพื่อใช้ตรวจสอบแบบ local:
GET /.well-known/jwks.json{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "key_...",
"alg": "RS256",
"n": "0vx7agoebG...",
"e": "AQAB"
}
]
}ระหว่างการหมุนคีย์อาจมีหลายคีย์พร้อมกัน ให้จับคู่ด้วย claim kid ใน JWT header
OIDC Discovery
ตั้งค่าไคลเอนต์อัตโนมัติจาก discovery document:
GET /.well-known/openid-configurationจะส่งคืน endpoints, algorithms ที่รองรับ และความสามารถต่าง ๆ ตามสเปก OpenID Connect Discovery
JWT Claims
โทเคนที่ตรวจสอบแล้วจะมีข้อมูล:
| Claim | คำอธิบาย |
|---|---|
iss |
URL ของผู้ออกโทเคน |
sub |
Subject (user ID หรือ client ID) |
aud |
กลุ่มเป้าหมายของโทเคน |
exp |
เวลาหมดอายุ (Unix timestamp) |
iat |
เวลาออกโทเคน (Unix timestamp) |
scope |
สิทธิ์ที่ได้รับ |
cid |
Client ID |
app |
Application ID |
acc |
Current account ID |
uid |
User ID (เมื่อเป็นผู้ใช้ที่ auth แล้ว) |
role |
บทบาทในบัญชีปัจจุบัน |
แคช
- แคชผลลัพธ์ JWKS (ใช้ ETag/If-None-Match)
- รีเฟรชเมื่อการตรวจสอบลายเซ็นล้มเหลว (กรณีหมุนคีย์)
- TTL ทั่วไป: 1 ชั่วโมง
Token Introspection
สำหรับ refresh token หรือกรณีที่ต้องการการตรวจสอบแบบ authoritative:
POST /oauth2/introspect
Content-Type: application/x-www-form-urlencoded
token=...&client_id=...&client_secret=...ผลลัพธ์จะมี active: true/false และ claims ของโทเคน ส่วน access token เป็น JWT จึงควรตรวจสอบแบบ local ผ่าน JWKS เมื่อเป็นไปได้
ที่เกี่ยวข้อง
- OAuth - การออกโทเคน
- ไคลเอนต์ - การตั้งค่าไคลเอนต์
- Client Key - คีย์สำหรับลงลายเซ็น