• oidc
  • oauth
  • token-exchange
  • openid

ทำความเข้าใจการแลกเปลี่ยนโทเค็นใน OAuth/OIDC

การแลกเปลี่ยนโทเค็นเป็นส่วนขยายของ OAuth ที่ช่วยให้ลูกค้าที่เชื่อถือได้สามารถรับโทเค็นใหม่ได้โดยไม่ต้องมีการโต้ตอบกับผู้ใช้ ซึ่งมีประโยชน์สำหรับการแกล้งตัวเป็นผู้อื่น การทำงานอัตโนมัติ การรวมระหว่างระบบ และการย้ายโทเค็นในหลากหลายสถานการณ์

Sijie
Sijie
Developer

แนะนำใน RFC 8693 การแลกเปลี่ยนโทเค็นเป็นส่วนขยายของ OAuth ที่อนุญาตให้ลูกค้าที่เชื่อถือได้แลกเปลี่ยนโทเค็นที่มีอยู่เพื่อรับโทเค็นใหม่ที่มีแอตทริบิวต์หรือขอบเขตที่แตกต่างกัน ซึ่งกลไกนี้มีประโยชน์โดยเฉพาะอย่างยิ่งสำหรับบริการ แอปพลิเคชัน หรือผู้ใช้ปลายทางในการรับโทเค็นการเข้าถึง OAuth ปกติผ่านโทเค็นที่ได้รับอนุญาตล่วงหน้า โดยไม่จำเป็นต้องผ่านกระบวนการ OAuth เต็มรูปแบบ

การเปรียบเทียบกับการไหลของรหัสอนุญาต

ก่อนอื่นมาดูที่กระบวนการไหลของรหัสอนุญาตของ OAuth ซึ่งเป็นกระบวนการที่ใช้บ่อยที่สุดในการรับโทเค็นการเข้าถึง

และนี่คือกระบวนการแลกเปลี่ยนโทเค็น:

การเปลี่ยนเส้นทาง

ความแตกต่างหลักคือในกระบวนการไหลของรหัสอนุญาต แอปพลิเคชันลูกค้าจะเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์อนุญาตเพื่อรับโทเค็นการเข้าถึง ในการแลกเปลี่ยนโทเค็น แอปพลิเคชันลูกค้าสามารถแลกเปลี่ยนโทเค็นกับเซิร์ฟเวอร์อนุญาตโดยไม่ต้องมีการเปลี่ยนเส้นทางของผู้ใช้

นั่นเป็นเพราะว่าในกระบวนการไหลของรหัสอนุญาต แอปพลิเคชันลูกค้าไม่ได้ "เชื่อถือได้" และต้องรู้ข้อมูลรับรองของผู้ใช้เพื่อรับโทเค็นการเข้าถึง ในการแลกเปลี่ยนโทเค็น แอปพลิเคชันลูกค้าได้รับการเชื่อถือว่าได้รับโทเค็นจากผู้ใช้แล้ว และเซิร์ฟเวอร์อนุญาตจะตรวจสอบความถูกต้องของโทเค็นและออกโทเค็นใหม่

ผู้ออกโทเค็นและบริการแลกเปลี่ยนโทเค็น

ในกระบวนการแลกเปลี่ยนโทเค็น "Auth Server" จะเป็นผู้เข้าร่วมสองคน:

  1. ผู้ออกโทเค็น: ออก subject token ให้กับแอปพลิเคชันลูกค้า
  2. บริการแลกเปลี่ยนโทเค็น: ตรวจสอบความถูกต้องของ subject token และออกโทเค็นใหม่ให้กับแอปพลิเคชันลูกค้า

บริการแลกเปลี่ยนโทเค็นเหมือนกับ "Auth Server" ในกระบวนการไหลของรหัสอนุญาต และผู้ออกโทเค็นสามารถเป็นผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม หรือแยกออกจาก "Auth Server" เป็นบริการเฉพาะ

เมื่อใดควรใช้การแลกเปลี่ยนโทเค็น?

กระบวนการแลกเปลี่ยนโทเค็นสามารถดำเนินการได้โดยไม่ต้องโต้ตอบกับผู้ใช้ สิ่งนี้มีประโยชน์ในสถานการณ์ต่อไปนี้:

  • การแกล้งตัวเป็นผู้อื่น: อนุญาตให้บริการ (เช่น microservices ฝั่งแบ็กเอนด์) หรือผู้ดูแลระบบ ดำเนินการในนามของผู้ใช้โดยไม่ต้องเปิดเผยข้อมูลรับรองของผู้ใช้
  • การทำงานอัตโนมัติ: อนุญาตให้บริการที่เชื่อถือได้ดำเนินการโดยอัตโนมัติโดยไม่ต้องแทรกแซงด้วยมือ หรือทำการทดสอบอัตโนมัติ
  • การรวมกับ IdP อื่น ๆ: แปลโทเค็นข้ามระบบข้อมูลประจำตัวต่าง ๆ เพื่อให้ประสบการณ์ผู้ใช้ราบรื่นและจัดการสิทธิ์ได้อย่างมีประสิทธิภาพ หนึ่งในสถานการณ์ทั่วไปคือการแปลโทเค็น SSO ไปเป็นโทเค็นสำหรับบริการปลายน้ำ
  • การย้าย: ย้ายโทเค็นจากเซิร์ฟเวอร์อนุญาตหนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง เช่น จากระบบเก่าไปยังระบบที่สอดคล้องกับ OAuth/OIDC สมัยใหม่

กระบวนการแลกเปลี่ยนโทเค็น

การแลกเปลี่ยนเพื่อรับโทเค็นการเข้าถึงใหม่เป็นการใช้ที่พบมากที่สุด เราจะใช้ตัวอย่างนี้ ไม่จำกัดเฉพาะโทเค็นการเข้าถึง การแลกเปลี่ยนโทเค็นยังสามารถใช้เพื่อออกโทเค็นประเภทอื่น เช่น โทเค็นรีเฟรช โทเค็น ID เป็นต้น

แอปพลิเคชันของลูกค้า

ในการดำเนินการแลกเปลี่ยนโทเค็นจำเป็นต้องมีแอปพลิเคชันลูกค้าที่ลงทะเบียนกับเซิร์ฟเวอร์อนุญาต

และแอปพลิเคชันของลูกค้าจะต้องมี subject_token ก่อนเริ่มกระบวนการแลกเปลี่ยนโทเค็น โทเค็นนี้มักจะได้รับจากเซิร์ฟเวอร์อนุญาตหรือผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สามที่เชื่อถือได้ ด้วยการมีโทเค็นนี้ แอปพลิเคชันลูกค้าสามารถ "เชื่อถือได้" ในการแลกเปลี่ยนโทเค็นโดยไม่ต้องมีข้อมูลรับรองและการโต้ตอบของผู้ใช้

การขอแลกเปลี่ยนโทเค็น

ลูกค้าจะส่งคำขอไปยังจุดสิ้นสุดของโทเค็นของเซิร์ฟเวอร์อนุญาตเพื่อแลกเปลี่ยนโทเค็นที่มีอยู่ สิ่งนี้รวมถึง subject_token (โทเค็นที่ถูกแลกเปลี่ยน) และตามต้องการ ขอบเขตเป้าหมาย ขอบเขต และประเภทของโทเค็นที่ต้องการ

  1. grant_type: จำเป็นต้องมี ค่าในพารามิเตอร์นี้จะต้องเป็น urn:ietf:params:oauth:grant-type:token-exchange ซึ่งระบุว่ามีการดำเนินการแลกเปลี่ยนโทเค็น
  2. subject_token: จำเป็นต้องมี PAT ของผู้ใช้
  3. subject_token_type: จำเป็นต้องมี ประเภทของโทเค็นความปลอดภัยที่ให้มาในพารามิเตอร์ subject_token ค่าทั่วไปของพารามิเตอร์นี้คือ `urn:ietf:params:oauth:token-type:access_token แต่สามารถเปลี่ยนแปลงได้ขึ้นอยู่กับโทเค็นที่ถูกแลกเปลี่ยน
  4. resource: ไม่บังคับ ตัวบ่งชี้ทรัพยากรช่วยระบุทรัพยากรเป้าหมายสำหรับโทเค็นการเข้าถึง
  5. audience: ไม่บังคับ กลุ่มเป้าหมายของโทเค็นการเข้าถึง ซึ่งบ่งชี้ผู้รับที่ตั้งใจของโทเค็น เซิร์ฟเวอร์อนุญาตอาจใช้ค่าของ resource หากไม่ได้ระบุ audience
  6. scope: ไม่บังคับ ขอบเขตที่ขอ

นอกจากนี้ คำขอยังต้องรวมถึงข้อมูลลูกค้าซึ่งสามารถเข้ารหัสเป็นส่วนหัวการรับรองความถูกต้องพื้นฐานหรือส่งเป็นข้อมูลฟอร์ม

ตัวอย่างคำขอนี้:

การแลกเปลี่ยนโทเค็นใน Logto

Logto รองรับการแลกเปลี่ยนโทเค็นออกจากกล่อง รวมถึง การแกล้งตัวเป็นผู้อื่น และ โทเค็นการเข้าถึงส่วนบุคคล.