โปรโตคอล OpenID Connect (OIDC) ได้กลายเป็นมาตรฐานที่ถูกนำไปใช้อย่างกว้างขวางในการจัดการอัตลักษณ์ แต่คุณเข้าใจบทบาทและคุณสมบัติของโทเค็นเหล่านี้จริง ๆ หรือไม่?
โปรโตคอล OpenID Connect, หรือที่เรียกว่า OIDC ได้กลายเป็นมาตรฐานที่ถูกนำไปใช้อย่างกว้างขวางในการให้กรอบพื้นฐานสำหรับการจัดการอัตลักษณ์ มันเป็นชั้นการยืนยันตัวที่ถูกสร้างขึ้นบน โปรโตคอล OAuth 2.0 ที่เป็นที่รู้จักกันดี ในขณะที่ OAuth 2.0 เพียงแค่เพื่ออนุญาตให้เข้าถึงทรัพยากร, OIDC เป็นโปรโตคอลที่มาตรฐานและเสริมการยืนยันตัวลูกค้าด้วยความช่วยเหลือจาก ID token ที่ถูกแนะนำใหม่
เดี๋ยวนะ... คุณอาจเคยได้ยินเกี่ยวกับ access tokens และ refresh tokens ในยุคของ OAuth และตอนนี้มีแนวคิดใหม่ใน OIDC? คุณเข้าใจความแตกต่างของโทเค็นเหล่านี้จริง ๆ หรือ?
เริ่มต้นด้วยสถานการณ์ที่เป็นจริง
ลองนึกภาพว่าคุณกำลังพัฒนาแอปพลิเคชันไคลเอนต์เซิร์ฟเวอร์ทั่วไป, และพวกมันสื่อสารระหว่างกันผ่าน RESTful APIs คุณต้องการให้ API ส่วนใหญ่ของคุณเป็นส่วนตัว, อนุญาตเฉพาะไคลเอนต์ที่มีสิทธิ์เท่านั้นที่สามารถเข้าถึงได้ คุณจะต้องใช้วิธีการในการยืนยันไคลเอนต์และอนุญาตคำขอ API ไปยังเซิร์ฟเวอร์ของคุณ
อุดมคติแล้ว, RESTful APIs ของคุณควรเป็นแบบไม่มีสภาวะ, หมายความว่าเซิร์ฟเวอร์ไม่ควรเก็บข้อมูลเซสชันของไคลเอนต์ เมื่อมีคำขอที่ถูกต้องเข้ามา, เซิร์ฟเวอร์ควรตอบกลับด้วยข้อมูลที่ร้องขอเท่านั้น นี่คือที่ที่โทเค็นเข้ามามีบทบาท ดังนั้น, ในกรณีเช่นนี้ควรใช้โทเค็นประเภทใด?
ใน OAuth 2.0 และ OIDC, แต่ละ API ที่ได้รับการปกป้องจะถือเป็นทรัพยากร access token คือโทเค็นที่ไคลเอนต์ส่งไปยังเซิร์ฟเวอร์เมื่อทำการร้องขอทรัพยากร API, โดยทั่วไปผ่านทาง header ของคำร้องขอและอยู่ในรูปแบบ JWT
ในฝั่งเซิร์ฟเวอร์, เมื่อใดก็ตามที่มีคำขอเข้ามา, เซิร์ฟเวอร์จำเป็นแค่ว่าจะตรวจสอบว่าคำขอที่เข้ามานำโทเค็นการเข้าถึงที่ถูกต้องหรือไม่ กระบวนการตรวจสอบประกอบด้วยการถอดรหัสโทเค็น JWT, การตรวจสอบลายเซ็นและเวลาหมดอายุ, รวมถึงคลาสที่จำเป็นเพื่อให้แน่ใจว่าไคลเอนต์มีสิทธิ์ที่จำเป็น
อย่างไรก็ตาม, คุณอาจคิด: หากแอปพลิเคชันไคลเอนต์ของฉันสามารถมี access token ที่ถูกต้องหลังจากการเข้าสู่ระบบสำเร็จ, และใช้ access token เพื่อร้องขอ API ของเซิร์ฟเวอร์, ไม่พอเพียงหรือ? ทำไมต้องมีโทเค็นอื่น?
คำถามที่ดียิ่ง, และขออธิบายทีละขั้นตอน
แม้ว่าทางเทคนิค access tokens จะตอบสนองความต้องการขั้นต่ำในการทำให้ระบบทำงานได้, แต่อย่างไรก็ตาม, เนื่องจากความกังวลด้านความปลอดภัย, อายุการใช้งานของ access tokens มักจะสั้นมาก (ปกติประมาณหนึ่งชั่วโมง) ดังนั้น ลองนึกภาพว่าหากเรามีแค่ access tokens แต่เพียงอย่างเดียว, ผู้ใช้จะต้องทำการยืนยันตัวตนอีกครั้งทุกครั้งที่ access token หมดอายุ สำหรับแอปพลิเคชันเว็บเพจเดียวสมัยใหม่ (SPAs) และแอปพลิเคชันมือถือ, การล็อกเอาท์บ่อยครั้งเป็นประสบการณ์ที่น่ารำคาญสำหรับผู้ใช้, ถึงแม้ว่าเราจะพยายามปกป้องความปลอดภัยของผู้ใช้ของพวกเขาก็ตาม
ดังนั้น, เราจึงต้องการความสมดุลระหว่างความปลอดภัยของโทเค็นและความสะดวกสบายของผู้ใช้ นั่นคือทำไม refresh tokens จึงถูกแนะนำ
access tokens ถูกใช้เพื่อเข้าถึงทรัพยากรของ API, ดังนั้นธรรมชาติที่มีอายุการใช้งานสั้นของพวกมันช่วยลดความเสี่ยงของการรั่วไหลหรือถูกการลักลอบ ในทางกลับกัน, เพราะ refresh tokens ถูกใช้เพื่อแลกเปลี่ยนเป็น access tokens ใหม่เท่านั้น, มันไม่ถูกใช้งานบ่อยเท่ากับ access tokens และดังนั้นความเสี่ยงของการเปิดเผยได้รับการลดลง ดังนั้น, การมีระยะเวลาที่มีผลนานขึ้นนั้นถือเป็นที่ยอมรับได้สำหรับ refresh tokens
เพราะ refresh token ยังถูกเก็บอยู่ในฝั่งไคลเอนต์, การทำให้แน่ใจว่ามันไม่ถูกลักลอบนั้นยาก, โดยเฉพาะอย่างยิ่งสำหรับลูกค้าสาธารณะเช่นแอปพลิเคชันเว็บเพจเดียว (SPA) และแอปพลิเคชันมือถือ
ใน Logto, refresh tokens มี กลไกการหมุนอัตโนมัติ เปิดโดยค่าเริ่มต้น, ซึ่งหมายความว่าเซิร์ฟเวอร์อนุญาตจะออก refresh token ใหม่เมื่อมันตรงตามเกณฑ์:
แม้ว่าคุณยังมีตัวเลือกที่จะปิดการหมุน refresh token ในหน้ารายละเอียดแอปพลิเคชันในคอนโซลผู้ดูแลระบบ, แนะนำให้คงมาตรการป้องกันนี้ไว้เป็นอย่างยิ่ง
ID token เป็นคุณลักษณะเฉพาะของ OIDC ที่ให้ข้อมูลอัตลักษณ์เกี่ยวกับผู้ใช้ที่ยืนยันตัวตน
ในขณะที่ access tokens ถูกใช้เพื่อเข้าถึงทรัพยากรที่ได้รับการปกป้องและ refresh tokens ถูกใช้เพื่อรับ access tokens ใหม่, ID tokens ถูกใช้เพื่อลดการร้องขอเพิ่มเติมไปยังเซิร์ฟเวอร์การอนุญาตเพื่อรับข้อมูลผู้ใช้เป็นส่วนใหญ่. ในกรณีส่วนใหญ่, มันปลอดภัยที่จะบอกว่าการมี ID token เท่ากับว่าผู้ใช้ได้ยืนยันตัวตนแล้ว.
ในโปรโตคอล OIDC, refresh tokens, access tokens, และ ID tokens ทำงานร่วมกันเพื่อให้การยืนยันตัวผู้ใช้งานที่ปลอดภัยและราบรื่น
การเข้าใจบทบาทและความสำคัญของโทเค็นเหล่านี้เป็นสิ่งสำคัญสำหรับนักพัฒนาที่กำลังใช้งาน OIDC ในแอปพลิเคชันของพวกเขา