การตรวจสอบสิทธิ์ของโทเค็น OAuth 2.0

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

เมตาดาทานี้รวมถึง:

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

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

มีสองประเภทของโทเค็นการเข้าถึง ขึ้นอยู่กับวิธีการเข้ารหัส:

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

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

การร้องขอตรวจสอบสิทธิ์ของโทเค็น#

การใช้โทเค็นการเข้าถึงตามตัวระบุต้องการการยืนยันกับเซิร์ฟเวอร์การอนุญาตผ่านการร้องขอเครือข่าย มีโปรโตคอลมาตรฐานสำหรับสิ่งนี้เรียกว่า 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