• oidc
  • oauth
  • api resource
  • jwt
  • access token
  • opaque token

เชื่อมจุด: สำรวจอย่างละเอียดเกี่ยวกับทรัพยากร OIDC และโทเค็นการเข้าถึง JWT ของคุณ

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

Charles
Charles
Developer

พื้นหลัง

ใน เซสชันก่อนหน้า เราได้แนะนำโปรโตคอล OpenID Connect (OIDC), โทเค็นรีเฟรช, โทเค็นการเข้าถึง และโทเค็น ID ซึ่งเป็นส่วนประกอบที่จำเป็นสำหรับการสร้างการยืนยันตัวตนในแอปพลิเคชันของคุณให้แข็งแกร่ง อย่างไรก็ตาม ชุมชนของเรายังคงมีคำถามอยู่ โดยคำถามหนึ่งที่พบมากคือ "ทำไมโทเค็นการเข้าถึงของฉันไม่ใช่ JWT?"

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

ทำความเข้าใจทรัพยากร OIDC

ถ้าคุณคุ้นเคยกับโปรโตคอล OAuth 2.0 คำว่า “resource” น่าจะคุ้นเคยดี เนื่องจาก OIDC ถูกสร้างขึ้นบนพื้นฐานของ OAuth 2.0 จึงสืบทอดแนวคิดนี้มา

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

ตามโปรโตคอล ทรัพยากรคือพารามิเตอร์ในคำขอไปยังเซิร์ฟเวอร์การอนุญาต เป็นค่าที่แสดงเป็น URI สมบูรณ์ เช่น https://my-company.com/api ทำหน้าที่เป็นตัวระบุสำหรับทรัพยากร อาจสอดคล้องกับตำแหน่งที่อยู่ในเครือข่ายหรือแม้แต่ URI ที่ไม่ซ้ำกันแต่เป็นเรื่องสมมุติ

ใน Logto คุณสามารถสร้าง “ทรัพยากร API” ผ่านหน้าคอนโซลผู้ดูแลระบบ→ ทรัพยากร API คุณสามารถดู เอกสารนี้ เพื่อดูรายละเอียดเพิ่มเติม

JWT โทเค็นการเข้าถึง

โทเค็นการเข้าถึงแบบ JWT (JSON web token) จะออกให้เฉพาะเมื่อมีการระบุตัวบ่งชี้ "ทรัพยากร" ระหว่างคำขอรับโทเค็นการเข้าถึง และมันจะบรรจุเซ็ตของคำอ้างสิทธิ์ ซึ่งคุณสามารถถอดรหัสและตรวจสอบได้ เช่น เพื่อยืนยันความครบถ้วนของโทเค็นและสิทธิ์ของผู้ใช้

และ "ทรัพยากร" นั้นจะกลายเป็นหนึ่งในคำอ้างสิทธิ์ aud โทเค็นใน JWT ซึ่งบ่งบอกถึงกลุ่มเป้าหมายที่ตั้งใจไว้สำหรับโทเค็น ดู RFC-7519

ดังนั้นความสัมพันธ์จึงชัดเจน:

  • ระบุตัวบ่งชี้ทรัพยากรเมื่อต้องการโทเค็น JWT
  • ตัวบ่งชี้ทรัพยากรจะสอดคล้องกับคำอ้างสิทธิ์ aud ของโทเค็น
  • เมื่อทำคำขอ API ต้องแนบโทเค็นการเข้าถึง JWT เป็นโทเค็นถือในส่วนหัว เซิร์ฟเวอร์ API ของคุณจะต้องถอดรหัสและตรวจสอบคำอ้างสิทธิ์ aud และคำอ้างสิทธิ์อื่น ๆ ที่เกี่ยวข้องกับสิทธิ์เพื่อรักษาความปลอดภัยของคำขอ API
  • โทเค็นการเข้าถึงแต่ละรายการจะสอดคล้องกับทรัพยากรเดียว หากคุณมีทรัพยากร API หลายตัวที่ลงทะเบียนด้วย URI ที่แตกต่างกัน ต้องขอโทเค็นการเข้าถึงที่แยกจากกันสำหรับแต่ละรายการ

🤔 แต่ถ้าลูกค้าไม่ระบุทรัพยากรเมื่อต้องการโทเค็นการเข้าถึงล่ะ?

Opaque โทเค็นการเข้าถึง

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

ใน Logto SDK ใด ๆ คุณสามารถรับโทเค็นเช่นนั้นได้หากคุณเรียก getAccessToken() หรือขอเอนด์พอยต์โทเค็น OIDC โดยตรงโดยไม่ระบุพารามิเตอร์ ทรัพยากร

โปรดทราบว่าโทเค็นการเข้าถึงแบบ opaque นี้ไม่เหมาะสมสำหรับคำขอทรัพยากร API ของคุณเอง เนื่องจากไม่มีวิธีการยืนยันโดยไม่ได้ขอเซิร์ฟเวอร์ OIDC

โดยสรุป

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

ใน Logto โทเค็นการเข้าถึงแบบ opaque มีไว้สำหรับดึงข้อมูลโปรไฟล์ผู้ใช้จากเอนด์พอยต์ userinfo ของ OIDC เท่านั้น ขณะที่ลูกค้าสามารถขอโทเค็นการเข้าถึงหลายตัว โดยแต่ละตัวจะทุ่มเทให้กับทรัพยากรเฉพาะ

เราหวังว่าโพสต์บล็อกนี้จะช่วยขจัดความสงสัยและเชื่อมต่อจุดต่าง ๆ ให้กับคุณ สามารถบอกความเห็นของคุณกับเราได้