บทความนี้สำรวจการตรวจสอบสิทธิ์ของโทเค็น OAuth 2.0 ซึ่งเป็นวิธีที่อนุญาตให้แหล่งข้อมูลที่ได้รับการป้องกันสอบถามเซิร์ฟเวอร์การอนุญาตเกี่ยวกับเมตาดาทาของโทเค็น เพื่อกำหนดว่าโทเค็นการเข้าถึงหรือรีเฟรชนั้นใช้งานได้หรือไม่
การตรวจสอบสิทธิ์ของโทเค็น OAuth 2.0 กำหนดวิธีการที่อนุญาตให้แหล่งข้อมูลที่ได้รับการป้องกันซึ่งได้รับอนุญาตสอบถามเซิร์ฟเวอร์การอนุญาตเพื่อตรวจสอบเมตาดาทาที่เกี่ยวข้องกับโทเค็นที่กำหนด (ไม่ว่าจะเป็นโทเค็นการเข้าถึงหรือโทเค็นการรีเฟรช) ที่ลูกค้า OAuth ให้มา ตามเมตาดาทาของโทเค็นเฉพาะนี้ จะอนุญาตให้เจ้าของแหล่งข้อมูลเข้าถึงทรัพยากรที่ได้รับการป้องกัน
เมตาดาทานี้รวมถึง:
การตรวจสอบสิทธิ์ของโทเค็นอนุญาตให้แหล่งข้อมูลที่ได้รับการป้องกันสอบถามข้อมูลนี้ได้ โดยไม่คำนึงว่าจะมีอยู่ภายในโทเค็นเองหรือไม่
มีสองประเภทของโทเค็นการเข้าถึง ขึ้นอยู่กับวิธีการเข้ารหัส:
สำหรับโทเค็นที่บรรจุตัวเอง เมตาดาทาที่เกี่ยวกับการอนุญาตสามารถถอดรหัสได้โดยตรงจากโทเค็นการเข้าถึง อย่างไรก็ตาม สำหรับโทเค็นตามตัวระบุ ฟังก์ชั่นการตรวจสอบสิทธิ์ของโทเค็นของเซิร์ฟเวอร์การอนุญาตต้องถูกใช้เพื่อยืนยัน/ดึงเมตาดาทา
การใช้โทเค็นการเข้าถึงตามตัวระบุต้องการการยืนยันกับเซิร์ฟเวอร์การอนุญาตผ่านการร้องขอเครือข่าย มีโปรโตคอลมาตรฐานสำหรับสิ่งนี้เรียกว่า OAuth 2.0 Token Introspection (RFC 7662)
ทรัพยากรที่ได้รับการป้องกันจะโพสต์โทเค็นไปที่จุดสิ้นสุดการตรวจสอบสิทธิ์ของเซิร์ฟเวอร์การอนุญาต และจะได้รับวัตถุ JSON ที่มีพารามิเตอร์ของโทเค็นนั้นแทน
โปรดทราบว่าการร้องขอตรวจสอบสิทธิ์ไม่สามารถเริ่มต้นโดยอำเภอใจได้ ต้องตรงตามหนึ่งในเงื่อนไขต่อไปนี้:
ผลจากการโต้ตอบเฉพาะนี้ ทรัพยากรที่ได้รับการป้องกันจะกลายเป็นลูกค้า OAuth และเซิร์ฟเวอร์การอนุญาตจะกลายเป็นทรัพยากรที่ได้รับการป้องกัน
ตัวอย่างด้านล่างนี้เป็นการร้องขอตรวจสอบสิทธิ์ ที่ทรัพยากรที่ได้รับการป้องกันยืนยันตัวตนโดยใช้รหัสลูกค้าและรหัสลับลูกค้า ซึ่งได้มาหลังจากการลงทะเบียนเป็นลูกค้า OAuth กับเซิร์ฟเวอร์การอนุญาต
ด้านล่างนี้เป็นตัวอย่างการร้องขอตรวจสอบสิทธิ์ที่ใช้โทเค็นการเข้าถึงโดยตรง โทเค็นการเข้าถึงสามารถได้โดยตรงจากจุดสิ้นสุด /token โดยใช้ข้อมูลประจำตัวของแอป machine-to-machine ที่ลงทะเบียนแล้วและประเภทการให้สิทธิ์ client_credentials
พารามิเตอร์ที่สำคัญที่สุดคือ active ซึ่งเป็นค่าบูลีน หาก true แสดงว่าโทเค็นนั้นใช้งานได้ วัตถุ JSON จะรวมถึงรายละเอียดของโทเค็นอื่นๆ เช่น ค่าของขอบเขต หาก false โทเค็นนั้นไม่ถูกต้องหรือหมดอายุแล้ว และทรัพยากรที่ได้รับการป้องกันจะต้องส่งคืนการตอบ 401 Unauthorized พร้อมรหัสข้อผิดพลาด invalid_token
นี่คือตัวอย่างการตอบกลับสำหรับโทเค็นที่ถูกต้อง:
นอกเหนือจาก active ที่จำเป็นแล้ว พารามิเตอร์อื่นๆ เป็นเพียงตัวเลือก
แหล่งข้อมูลที่ได้รับการป้องกันสามารถใช้ฟิลด์เพิ่มเติมเหล่านี้เพื่อตรวจสอบสิทธิ์การเข้าถึง เหมือนกับวิธีที่มันจะถอดและยืนยันโทเค็นการเข้าถึง JWT