แนะนำใน RFC 8693 การแลกเปลี่ยนโทเค็นเป็นส่วนขยายของ OAuth ที่อนุญาตให้ลูกค้าที่เชื่อถือได้แลกเปลี่ยนโทเค็นที่มีอยู่เพื่อรับโทเค็นใหม่ที่มีแอตทริบิวต์หรือขอบเขตที่แตกต่างกัน ซึ่งกลไกนี้มีประโยชน์โดยเฉพาะอย่างยิ่งสำหรับบริการ แอปพลิเคชัน หรือผู้ใช้ปลายทางในการรับโทเค็นการเข้าถึง OAuth ปกติผ่านโทเค็นที่ได้รับอนุญาตล่วงหน้า โดยไม่จำเป็นต้องผ่านกระบวนการ OAuth เต็มรูปแบบ
การเปรียบเทียบกับการไหลของรหัสอนุญาต#
ก่อนอื่นมาดูที่กระบวนการไหลของรหัสอนุญาตของ OAuth ซึ่งเป็นกระบวนการที่ใช้บ่อยที่สุดในการรับโทเค็นการเข้าถึง
และนี่คือกระบวนการแลกเปลี่ยนโทเค็น:
การเปลี่ยนเส้นทาง#
ความแตกต่างหลักคือในกระบวนการไหลของรหัสอนุญาต แอปพลิเคชันลูกค้าจะเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์อนุญาตเพื่อรับโทเค็นการเข้าถึง ในการแลกเปลี่ยนโทเค็น แอปพลิเคชันลูกค้าสามารถแลกเปลี่ยนโทเค็นกับเซิร์ฟเวอร์อนุญาตโดยไม่ต้องมีการเปลี่ยนเส้นทางของผู้ใช้
นั่นเป็นเพราะว่าในกระบวนการไหลของรหัสอนุญาต แอปพลิเคชันลูกค้าไม่ได้ "เชื่อถือได้" และต้องรู้ข้อมูลรับรองของผู้ใช้เพื่อรับโทเค็นการเข้าถึง ในการแลกเปลี่ยนโทเค็น แอปพลิเคชันลูกค้าได้รับการเชื่อถือว่าได้รับโทเค็นจากผู้ใช้แล้ว และเซิร์ฟเวอร์อนุญาตจะตรวจสอบความถูกต้องของโทเค็นและออกโทเค็นใหม่
ผู้ออกโทเค็นและบริการแลกเปลี่ยนโทเค็น#
ในกระบวนการแลกเปลี่ยนโทเค็น "Auth Server" จะเป็นผู้เข้าร่วมสองคน:
- ผู้ออกโทเค็น: ออก subject token ให้กับแอปพลิเคชันลูกค้า
- บริการแลกเปลี่ยนโทเค็น: ตรวจสอบความถูกต้องของ subject token และออกโทเค็นใหม่ให้กับแอปพลิเคชันลูกค้า
บริการแลกเปลี่ยนโทเค็นเหมือนกับ "Auth Server" ในกระบวนการไหลของรหัสอนุญาต และผู้ออกโทเค็นสามารถเป็นผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม หรือแยกออกจาก "Auth Server" เป็นบริการเฉพาะ
เมื่อใดควรใช้การแลกเปลี่ยนโทเค็น?#
กระบวนการแลกเปลี่ยนโทเค็นสามารถดำเนินการได้โดยไม่ต้องโต้ตอบกับผู้ใช้ สิ่งนี้มีประโยชน์ในสถานการณ์ต่อไปนี้:
- การแกล้งตัวเป็นผู้อื่น: อนุญาตให้บริการ (เช่น microservices ฝั่งแบ็กเอนด์) หรือผู้ดูแลระบบ ดำเนินการในนามของผู้ใช้โดยไม่ต้องเปิดเผยข้อมูลรับรองของผู้ใช้
- การทำงานอัตโนมัติ: อนุญาตให้บริการที่เชื่อถือได้ดำเนินการโดยอัตโนมัติโดยไม่ต้องแทรกแซงด้วยมือ หรือทำการทดสอบอัตโนมัติ
- การรวมกับ IdP อื่น ๆ: แปลโทเค็นข้ามระบบข้อมูลประจำตัวต่าง ๆ เพื่อให้ประสบการณ์ผู้ใช้ราบรื่นและจัดการสิทธิ์ได้อย่างมีประสิทธิภาพ หนึ่งในสถานการณ์ทั่วไปคือการแปลโทเค็น SSO ไปเป็นโทเค็นสำหรับบริการปลายน้ำ
- การย้าย: ย้ายโทเค็นจากเซิร์ฟเวอร์อนุญาตหนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง เช่น จากระบบเก่าไปยังระบบที่สอดคล้องกับ OAuth/OIDC สมัยใหม่
กระบวนการแลกเปลี่ยนโทเค็น#
การแลกเปลี่ยนเพื่อรับโทเค็นการเข้าถึงใหม่เป็นการใช้ที่พบมากที่สุด เราจะใช้ตัวอย่างนี้ ไม่จำกัดเฉพาะโทเค็นการเข้าถึง การแลกเปลี่ยนโทเค็นยังสามารถใช้เพื่อออกโทเค็นประเภทอื่น เช่น โทเค็นรีเฟรช โทเค็น ID เป็นต้น
แอปพลิเคชันของลูกค้า#
ในการดำเนินการแลกเปลี่ยนโทเค็นจำเป็นต้องมีแอปพลิเคชันลูกค้าที่ลงทะเบียนกับเซิร์ฟเวอร์อนุญาต
และแอปพลิเคชันของลูกค้าจะต้องมี subject_token ก่อนเริ่มกระบวนการแลกเปลี่ยนโทเค็น โทเค็นนี้มักจะได้รับจากเซิร์ฟเวอร์อนุญาตหรือผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สามที่เชื่อถือได้ ด้วยการมีโทเค็นนี้ แอปพลิเคชันลูกค้าสามารถ "เชื่อถือได้" ในการแลกเปลี่ยนโทเค็นโดยไม่ต้องมีข้อมูลรับรองและการโต้ตอบของผู้ใช้
การขอแลกเปลี่ยนโทเค็น#
ลูกค้าจะส่งคำขอไปยังจุดสิ้นสุดของโทเค็นของเซิร์ฟเวอร์อนุญาตเพื่อแลกเปลี่ยนโทเค็นที่มีอยู่ สิ่งนี้รวมถึง subject_token (โทเค็นที่ถูกแลกเปลี่ยน) และตามต้องการ ขอบเขตเป้าหมาย ขอบเขต และประเภทของโทเค็นที่ต้องการ
grant_type: จำเป็นต้องมี ค่าในพารามิเตอร์นี้จะต้องเป็น urn:ietf:params:oauth:grant-type:token-exchange ซึ่งระบุว่ามีการดำเนินการแลกเปลี่ยนโทเค็น
subject_token: จำเป็นต้องมี PAT ของผู้ใช้
subject_token_type: จำเป็นต้องมี ประเภทของโทเค็นความปลอดภัยที่ให้มาในพารามิเตอร์ subject_token ค่าทั่วไปของพารามิเตอร์นี้คือ `urn:ietf:params:oauth:token-type:access_token แต่สามารถเปลี่ยนแปลงได้ขึ้นอยู่กับโทเค็นที่ถูกแลกเปลี่ยน
resource: ไม่บังคับ ตัวบ่งชี้ทรัพยากรช่วยระบุทรัพยากรเป้าหมายสำหรับโทเค็นการเข้าถึง
audience: ไม่บังคับ กลุ่มเป้าหมายของโทเค็นการเข้าถึง ซึ่งบ่งชี้ผู้รับที่ตั้งใจของโทเค็น เซิร์ฟเวอร์อนุญาตอาจใช้ค่าของ resource หากไม่ได้ระบุ audience
scope: ไม่บังคับ ขอบเขตที่ขอ
นอกจากนี้ คำขอยังต้องรวมถึงข้อมูลลูกค้าซึ่งสามารถเข้ารหัสเป็นส่วนหัวการรับรองความถูกต้องพื้นฐานหรือส่งเป็นข้อมูลฟอร์ม
ตัวอย่างคำขอนี้:
การแลกเปลี่ยนโทเค็นใน Logto#
Logto รองรับการแลกเปลี่ยนโทเค็นออกจากกล่อง รวมถึง การแกล้งตัวเป็นผู้อื่น และ โทเค็นการเข้าถึงส่วนบุคคล.