Claims และ ID Tokens ของ OpenID Connect

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

โทเค็น ID ของ OIDC คือโทเค็นเว็บ JSON (JWT) ที่มีข้ออ้างสิทธิ์เกี่ยวกับผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์แล้ว JWT ลงลายเซ็นโดยเซิร์ฟเวอร์การอนุญาตด้วยคีย์ส่วนตัว (โดยทั่วไปคือ RS256 หรือ ES256) และฝ่ายผู้พึ่งพา (แอปพลิเคชันไคลเอ็นต์) ตรวจสอบลายเซ็นโดยใช้คีย์สาธารณะที่เซิร์ฟเวอร์การอนุญาตเผยแพร่ (จุดปลายทาง JWKS)

ข้ออ้างสิทธิ์ของโทเค็น ID ที่จำเป็นและใช้กันทั่วไป ได้แก่ "sub" (หัวเรื่อง ตัวระบุผู้ใช้ที่ไม่ซ้ำกัน) "iss" (ผู้ออก URL ของเซิร์ฟเวอร์การอนุญาต) "aud" (ผู้รับ โคตรหัสไคลเอ็นต์) "exp" (การหมดอายุ การประทับเวลา Unix) "iat" (เวลาที่ออก การประทับเวลา Unix) ข้ออ้างสิทธิ์ที่ไม่บังคับ ได้แก่ "auth_time" (เวลาที่เกิดการตรวจสอบสิทธิ์) "nonce" (การป้องกันการเล่นซ้ำ) "at_hash" (แฮชของโทเค็นการเข้าถึง) "acr" (คลาสบริบทการตรวจสอบสิทธิ์) และ "amr" (วิธีการตรวจสอบสิทธิ์ที่ใช้)

จุดปลายทาง UserInfo ของ OIDC ส่งคืนข้ออ้างสิทธิ์เพิ่มเติมเกี่ยวกับผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์แล้วเมื่อเรียกใช้ด้วยโทเค็นการเข้าถึงที่ถูกต้อง ไคลเอ็นต์จะขอชุดข้ออ้างสิทธิ์ที่ต้องการผ่านขอบเขต ได้แก่ "profile" (ชื่อ รูปภาพ ภาษาท้องถิ่น) "email" (อีเมล email_verified) "address" (ที่อยู่ในรูปแบบมาตรฐาน) และ "phone" (phone_number, phone_number_verified) การตอบกลับจาก UserInfo เป็นออบเจ็กต์ JSON หรือ JWT

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

หลังจากตรวจสอบลายเซ็นแล้ว ไคลเอ็นต์ต้องตรวจสอบดังนี้ "iss" ต้องตรงกับ URL ของเซิร์ฟเวอร์การอนุญาตที่คาดหมายทุกประการ (รวมทั้งโครงร่างและเส้นทาง) "aud" ต้องมี client_id ของไคลเอ็นต์เอง "exp" ต้องเป็นเวลาในอนาคต (ปฏิเสธโทเค็นที่หมดอายุแล้ว) และ "iat" ควรเป็นเวลาที่ผ่านมาไม่นานเกินสมควร การตรวจสอบทั้งสี่รายการเป็นข้อบังคับตามข้อกำหนดของ OIDC

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

เมื่อ OIDC ใช้กระบวนการโดยนัย (response_type=id_token) โทเค็น ID จะถูกส่งกลับโดยตรงในส่วนแฟรกเมนต์ของ URL ไคลเอ็นต์ต้องตรวจสอบ at_hash (แฮชของโทเค็นการเข้าถึง) เพื่อผูกโทเค็นการเข้าถึงเข้ากับโทเค็น ID หากไม่ตรวจสอบ at_hash อาจเกิดการโจมตีแบบสวมแทนโทเค็นการเข้าถึงได้ นี่เป็นอีกเหตุผลหนึ่งที่กระบวนการโดยนัยถูกยกเลิกการแนะนำ

OIDC กำหนดการจับคู่มาตรฐานระหว่างขอบเขตกับข้ออ้างสิทธิ์ ขอบเขต "openid" เป็นข้อบังคับและส่งคืนข้ออ้างสิทธิ์ "sub" ขอบเขต "profile" ส่งคืน name, given_name, family_name, nickname, picture, website, locale, zoneinfo และ updated_at ขอบเขต "email" ส่งคืน email และ email_verified การขอขอบเขตที่ไม่จำเป็นละเมิดหลักการเปิดเผยข้อมูลเท่าที่จำเป็นและอาจทำให้ข้อมูลผู้ใช้ที่ละเอียดอ่อนถูกเปิดเผย

เมื่อนำการเข้าสู่ระบบ OIDC จากผู้ให้บริการหลายรายไปใช้ (เช่น "ลงชื่อเข้าใช้ด้วย Google" และ "ลงชื่อเข้าใช้ด้วย GitHub") อาจเกิดการโจมตีแบบแทรกข้ออ้างสิทธิ์ได้ หากผู้โจมตีสร้างบัญชีกับผู้ให้บริการ B โดยใช้อีเมลของเหยื่อที่ใช้ผู้ให้บริการ A ผู้โจมตีอาจเข้าถึงบัญชีได้ หากแอปพลิเคชันจับคู่บัญชีโดยใช้ข้ออ้างสิทธิ์อีเมลเพียงอย่างเดียว ควรจับคู่บัญชีด้วยคู่ (iss, sub) เสมอ ไม่ใช้อีเมลเพียงอย่างเดียว

กระบวนการแบบผสมของ OIDC (response_type=code id_token) ส่งคืนทั้งรหัสการอนุญาตและโทเค็น ID จากจุดปลายทางการอนุญาต โทเค็น ID ช่วยให้ตรวจสอบข้อมูลระบุตัวตนได้ทันที ขณะที่รหัสจะถูกแลกเป็นโทเค็นผ่านช่องทางเบื้องหลัง ใช้กระบวนการนี้เมื่อไคลเอ็นต์ต้องแสดงข้อมูลผู้ใช้ทันที ก่อนดำเนินการแลกเปลี่ยนโทเค็นผ่านช่องทางเบื้องหลังให้เสร็จสิ้น

ฝ่ายผู้พึ่งพาต้องตรวจสอบข้ออ้างสิทธิ์ชุดใดในโทเค็น ID ของ OIDC

OIDC เพิ่มโทเค็น ID แบบ JWT ที่มีลายเซ็นลงในกระบวนการ OAuth 2.0 ให้ตรวจสอบลายเซ็น (JWKS), iss (ต้องตรงกันทุกประการ), aud (client_id), exp (ต้องไม่หมดอายุ) และ nonce (หากมีการส่ง) จุดปลายทาง UserInfo ให้ข้ออ้างสิทธิ์เพิ่มเติมผ่านขอบเขต จับคู่บัญชีด้วยคู่ (iss, sub) เท่านั้น ห้ามใช้อีเมลเพียงอย่างเดียว เพื่อป้องกันการแทรกข้ออ้างสิทธิ์ กระบวนการโดยนัยถูกยกเลิกการแนะนำ ให้ใช้รหัสการอนุญาตร่วมกับ PKCE สำหรับ OIDC