โฟลว์ OAuth 2.0 และประเภทโทเค็น

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

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

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

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

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

กระบวนการการอนุญาตอุปกรณ์ (RFC 8628) ทำให้สามารถใช้ OAuth บนอุปกรณ์ที่มีความสามารถด้านการป้อนข้อมูลจำกัด เช่น สมาร์ททีวี เครื่องเล่นเกม เครื่องพิมพ์ และอุปกรณ์ IoT อุปกรณ์จะแสดงรหัสสั้นและ URL จากนั้นผู้ใช้จะเปิด URL บนโทรศัพท์หรือคอมพิวเตอร์เพื่ออนุญาต อุปกรณ์จะส่งคำขอสอบถามเซิร์ฟเวอร์การอนุญาตซ้ำ ๆ จนกว่าผู้ใช้จะดำเนินการอนุญาตเสร็จสมบูรณ์

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

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

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

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

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

กระบวนการรหัสการอนุญาตเหมาะสมสำหรับแอปฝั่งเซิร์ฟเวอร์ กระบวนการแบบ Implicit เลิกใช้แล้ว จึงควรใช้ PKCE แทน กระบวนการ ROPC เลิกใช้แล้ว เพราะขจัดจุดประสงค์ของ OAuth กระบวนการข้อมูลรับรองไคลเอนต์ใช้สำหรับ M2M การอนุญาตอุปกรณ์รองรับอุปกรณ์ที่มีข้อจำกัดด้านการป้อนข้อมูล โทเค็นการเข้าถึงมีทั้งแบบทึบแสงและ JWT โทเค็นสำหรับต่ออายุควรมีการหมุนเวียน การตรวจสอบโทเค็น (RFC 7662) และการเพิกถอนโทเค็น (RFC 7009) ช่วยให้การจัดการโทเค็นสมบูรณ์