ทำความเข้าใจ access tokens, refresh tokens, และ ID tokens ในโปรโตคอล OpenID Connect (OIDC)

OIDC, OAuth 2.0, และโทเค็น#

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

เดี๋ยวนะ... คุณอาจเคยได้ยินเกี่ยวกับ access tokens และ refresh tokens ในยุคของ OAuth และตอนนี้มีแนวคิดใหม่ใน OIDC? คุณเข้าใจความแตกต่างของโทเค็นเหล่านี้จริง ๆ หรือ?

access tokens, refresh tokens, และ ID tokens ใน OIDC คืออะไร?#

เริ่มต้นด้วยสถานการณ์ที่เป็นจริง

ลองนึกภาพว่าคุณกำลังพัฒนาแอปพลิเคชันไคลเอนต์เซิร์ฟเวอร์ทั่วไป, และพวกมันสื่อสารระหว่างกันผ่าน RESTful APIs คุณต้องการให้ API ส่วนใหญ่ของคุณเป็นส่วนตัว, อนุญาตเฉพาะไคลเอนต์ที่มีสิทธิ์เท่านั้นที่สามารถเข้าถึงได้ คุณจะต้องใช้วิธีการในการยืนยันไคลเอนต์และอนุญาตคำขอ API ไปยังเซิร์ฟเวอร์ของคุณ

อุดมคติแล้ว, RESTful APIs ของคุณควรเป็นแบบไม่มีสภาวะ, หมายความว่าเซิร์ฟเวอร์ไม่ควรเก็บข้อมูลเซสชันของไคลเอนต์ เมื่อมีคำขอที่ถูกต้องเข้ามา, เซิร์ฟเวอร์ควรตอบกลับด้วยข้อมูลที่ร้องขอเท่านั้น นี่คือที่ที่โทเค็นเข้ามามีบทบาท ดังนั้น, ในกรณีเช่นนี้ควรใช้โทเค็นประเภทใด?

Access tokens ถูกใช้เพื่อปกป้อง APIs ของคุณ#

ใน OAuth 2.0 และ OIDC, แต่ละ API ที่ได้รับการปกป้องจะถือเป็นทรัพยากร access token คือโทเค็นที่ไคลเอนต์ส่งไปยังเซิร์ฟเวอร์เมื่อทำการร้องขอทรัพยากร API, โดยทั่วไปผ่านทาง header ของคำร้องขอและอยู่ในรูปแบบ JWT

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

อย่างไรก็ตาม, คุณอาจคิด: หากแอปพลิเคชันไคลเอนต์ของฉันสามารถมี access token ที่ถูกต้องหลังจากการเข้าสู่ระบบสำเร็จ, และใช้ access token เพื่อร้องขอ API ของเซิร์ฟเวอร์, ไม่พอเพียงหรือ? ทำไมต้องมีโทเค็นอื่น?

คำถามที่ดียิ่ง, และขออธิบายทีละขั้นตอน

ทำไมเราจึงต้องมี refresh tokens?#

แม้ว่าทางเทคนิค access tokens จะตอบสนองความต้องการขั้นต่ำในการทำให้ระบบทำงานได้, แต่อย่างไรก็ตาม, เนื่องจากความกังวลด้านความปลอดภัย, อายุการใช้งานของ access tokens มักจะสั้นมาก (ปกติประมาณหนึ่งชั่วโมง) ดังนั้น ลองนึกภาพว่าหากเรามีแค่ access tokens แต่เพียงอย่างเดียว, ผู้ใช้จะต้องทำการยืนยันตัวตนอีกครั้งทุกครั้งที่ access token หมดอายุ สำหรับแอปพลิเคชันเว็บเพจเดียวสมัยใหม่ (SPAs) และแอปพลิเคชันมือถือ, การล็อกเอาท์บ่อยครั้งเป็นประสบการณ์ที่น่ารำคาญสำหรับผู้ใช้, ถึงแม้ว่าเราจะพยายามปกป้องความปลอดภัยของผู้ใช้ของพวกเขาก็ตาม

ดังนั้น, เราจึงต้องการความสมดุลระหว่างความปลอดภัยของโทเค็นและความสะดวกสบายของผู้ใช้ นั่นคือทำไม refresh tokens จึงถูกแนะนำ

ทำไม refresh tokens จึงสามารถมีอายุการใช้งานที่ยาวนานกว่า?#

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

การรักษาความปลอดภัยของ refresh token#

เพราะ refresh token ยังถูกเก็บอยู่ในฝั่งไคลเอนต์, การทำให้แน่ใจว่ามันไม่ถูกลักลอบนั้นยาก, โดยเฉพาะอย่างยิ่งสำหรับลูกค้าสาธารณะเช่นแอปพลิเคชันเว็บเพจเดียว (SPA) และแอปพลิเคชันมือถือ

ใน Logto, refresh tokens มี กลไกการหมุนอัตโนมัติ เปิดโดยค่าเริ่มต้น, ซึ่งหมายความว่าเซิร์ฟเวอร์อนุญาตจะออก refresh token ใหม่เมื่อมันตรงตามเกณฑ์:

• แอปพลิเคชันหน้าเดียว: ถูกจดจำว่าเป็นลูกค้าไม่มีการยับยั้งผู้ส่ง, แอปเหล่านี้บังคับให้หมุน refresh token. เวลาในการมีชีวิต (TTL) ของ refresh token ไม่สามารถระบุได้
• แอปดั้งเดิมและแอปเว็บแบบดั้งเดิม: การหมุน refresh token ได้รับการเปิดใช้งานโดยธรรมชาติ, การหมุนอัตโนมัติเมื่อตรงตาม 70% ของ TTL ของมัน เรียนรู้เพิ่มเติมเกี่ยวกับ การหมุน refresh token ใน Logto

แม้ว่าคุณยังมีตัวเลือกที่จะปิดการหมุน refresh token ในหน้ารายละเอียดแอปพลิเคชันในคอนโซลผู้ดูแลระบบ, แนะนำให้คงมาตรการป้องกันนี้ไว้เป็นอย่างยิ่ง

ID token คืออะไรและทำไมมันถึงสำคัญ?#

ID token เป็นคุณลักษณะเฉพาะของ OIDC ที่ให้ข้อมูลอัตลักษณ์เกี่ยวกับผู้ใช้ที่ยืนยันตัวตน

ในขณะที่ access tokens ถูกใช้เพื่อเข้าถึงทรัพยากรที่ได้รับการปกป้องและ refresh tokens ถูกใช้เพื่อรับ access tokens ใหม่, ID tokens ถูกใช้เพื่อลดการร้องขอเพิ่มเติมไปยังเซิร์ฟเวอร์การอนุญาตเพื่อรับข้อมูลผู้ใช้เป็นส่วนใหญ่. ในกรณีส่วนใหญ่, มันปลอดภัยที่จะบอกว่าการมี ID token เท่ากับว่าผู้ใช้ได้ยืนยันตัวตนแล้ว.

แนวทางที่ดีที่สุดในการจัดการโทเค็น#

• ใช้ HTTPS: ใช้ HTTPS เสมอเพื่อป้องกันการสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์อนุญาต นี่จะช่วยป้องกันไม่ให้ผู้ไม่มีสิทธิ์ดักฟังและขโมยโทเค็น
• ตั้งค่าเวลาหมดอายุโทเค็นให้เหมาะสม: Access tokens ควรมีอายุการใช้งานสั้นเพื่อที่จะลดความเสี่ยงของการเปิดเผย Refresh tokens สามารถมีระยะเวลาที่มีผลนานกว่า
• เปิดใช้การหมุน refresh token: ใช้การหมุน refresh token เพื่อบรรเทาความเสี่ยงจากการรั่วไหลของ refresh token
• ใช้การควบคุมการเข้าถึงที่ละเอียด: ใช้ขอบเขตที่ละเอียดเพื่อลดสิทธิ์ของ access tokens ขอเฉพาะสิทธิ์ที่จำเป็นสำหรับแอปพลิเคชันของไคลเอนต์เท่านั้น หลีกเลี่ยงการใช้ "all" หรือ "admin" ขอบเขตเพื่อข้ามการตรวจสอบสิทธิ์เกือบทั้งหมดหากไม่จำเป็นอย่างยิ่ง

สรุป: ความแตกต่างสำคัญของ access tokens, refresh tokens, และ ID tokens ใน OIDC#

ในโปรโตคอล OIDC, refresh tokens, access tokens, และ ID tokens ทำงานร่วมกันเพื่อให้การยืนยันตัวผู้ใช้งานที่ปลอดภัยและราบรื่น

• Access tokens ให้การอนุญาตในการเข้าถึงทรัพยากรที่ได้รับการปกป้อง
• Refresh tokens ขจัดการแทรกแซงของผู้ใช้สำหรับการรับ access tokens ใหม่
• ID tokens ให้ข้อมูลผู้ใช้แคชในไคลเอนต์, เพิ่มประสิทธิภาพ

การเข้าใจบทบาทและความสำคัญของโทเค็นเหล่านี้เป็นสิ่งสำคัญสำหรับนักพัฒนาที่กำลังใช้งาน OIDC ในแอปพลิเคชันของพวกเขา