0Pricing
OAuth2 & OpenID Connect Deep Dive · บทเรียน

การแลกเปลี่ยนโทเค็น (RFC 8693)

เรียนรู้ส่วนขยายการแลกเปลี่ยนโทเค็นของ OAuth2 ที่ให้บริการแลกโทเค็นหนึ่งเป็นอีกโทเค็น เพื่อรองรับการมอบสิทธิ์และการปลอมเป็นผู้ใช้งานข้ามขอบเขตบริการ

การแลกเปลี่ยนโทเค็น (RFC 8693) เป็นบทเรียน OAuth2 & OpenID Connect Deep Dive ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน OAuth2 & OpenID Connect Deep Dive และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส OAuth2 & OpenID Connect Deep Dive มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

What Problem Does It Solve?

In a microservices world, Service A receives a token from a user, then must call Service B on the user's behalf. Forwarding the original token everywhere is risky — it may have the wrong audience or too-broad scopes.

Token Exchange (RFC 8693) lets a service trade an incoming token for a new, narrower or differently-scoped token from the authorization server.

Delegation vs Impersonation

Two distinct patterns:

  • Impersonation — the new token looks like it belongs purely to the user; downstream cannot tell a middle service was involved.
  • Delegation — the new token records both the user and the acting service via an act claim, preserving the chain.

The Grant Type

Token Exchange defines a new grant type sent to the standard token endpoint:

urn:ietf:params:oauth:grant-type:token-exchange

It does not need a browser or user interaction — it is a direct back-channel call.

Key Parameters

The request uses several parameters:

  • subject_token + subject_token_type — the token to exchange.
  • actor_token — optional, identifies the acting party.
  • audience / resource — the target service.
  • scope — requested scopes for the new token.

Token Type URIs

Token types are identified by URIs, for example:

  • urn:ietf:params:oauth:token-type:access_token
  • urn:ietf:params:oauth:token-type:jwt
  • urn:ietf:params:oauth:token-type:id_token

An Exchange Request

Service A exchanges the user's access token for a token scoped to Service B:

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJhbGciOi...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=https://serviceB.example.com
&scope=read:orders

The Exchange Response

The response includes the new token plus an issued_token_type telling the caller what it received.

{
  "access_token": "eyJ0eXAiOi...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 600,
  "scope": "read:orders"
}

The act Claim

In delegation mode, the issued JWT contains an act (actor) claim nesting the acting party inside the subject. This lets the resource server audit who acted on whose behalf.

{
  "sub": "user-42",
  "aud": "https://serviceB.example.com",
  "act": { "sub": "service-A" }
}

Downscoping

A powerful use is downscoping: a service holding a broad token exchanges it for one with fewer scopes before passing it downstream. This honors least privilege so a compromised downstream service cannot do more than it needs.

When to Use It

Reach for Token Exchange when:

  • Crossing trust or audience boundaries between services.
  • You need an auditable delegation chain.
  • You want to narrow scopes for downstream calls.

Avoid blindly forwarding the original token across services.

Security Notes

The authorization server must authenticate the requesting client and verify it is permitted to exchange the subject token for the requested audience. Always set a correct aud so tokens cannot be replayed against other services.

Quick Check

Check your grasp of Token Exchange.

Recap

Token Exchange (RFC 8693) trades one token for another via grant type token-exchange.

  • Supports impersonation and delegation (the act claim).
  • Lets services downscope and re-audience tokens for downstream calls.
  • Requires the AS to authenticate the client and validate the target audience.

คำถามที่พบบ่อย

บทเรียน “การแลกเปลี่ยนโทเค็น (RFC 8693)” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การแลกเปลี่ยนโทเค็น (RFC 8693)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส OAuth2 & OpenID Connect Deep Dive ให้อัปเกรดเป็น CoddyKit PRO คอร์ส OAuth2 & OpenID Connect Deep Dive มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การแลกเปลี่ยนโทเค็น (RFC 8693)”

เรียนรู้ส่วนขยายการแลกเปลี่ยนโทเค็นของ OAuth2 ที่ให้บริการแลกโทเค็นหนึ่งเป็นอีกโทเค็น เพื่อรองรับการมอบสิทธิ์และการปลอมเป็นผู้ใช้งานข้ามขอบเขตบริการ คุณปฏิบัติ OAuth2 & OpenID Connect Deep Dive ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน OAuth2 & OpenID Connect Deep Dive หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน OAuth2 & OpenID Connect Deep Dive บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การแลกเปลี่ยนโทเค็น (RFC 8693)” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน OAuth2 & OpenID Connect Deep Dive นี้ได้ไหม

ได้ บทเรียน OAuth2 & OpenID Connect Deep Dive ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. PKCE สำหรับไคลเอ็นต์สาธารณะ
  2. โทเค็นต่ออายุและขอบเขต
  3. ข้อมูลรับรองรหัสผ่านของเจ้าของทรัพยากร
  4. การแลกเปลี่ยนโทเค็น (RFC 8693)
← กลับไปที่ OAuth2 & OpenID Connect Deep Dive