โทเค็น Opaque กับ JWT

ใน Logto ซึ่งเป็นแพลตฟอร์ม CIAM ที่ครอบคลุมและใช้พื้นฐานจาก OIDC, โทเค็นอนุญาตมีบทบาทสำคัญในการรักษาความปลอดภัยของการโต้ตอบของผู้ใช้และการจัดการการเข้าถึงทรัพยากร ในบรรดาประเภทต่าง ๆ ของโทเค็นที่ใช้สำหรับอนุญาต โทเค็น Opaque และ JWTs (JSON Web Tokens) นับว่าเป็นสิ่งที่สำคัญที่สุด

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

โทเค็น Opaque คืออะไร?#

โทเค็น Opaque เป็นประเภทของโทเค็นการเข้าถึงที่ตามชื่อก็คือไม่โปร่งใสต่อไคลเอ็นต์หรือบุคคลภายนอกใด ๆ ซึ่งหมายความว่าโทเค็นเองไม่ได้มีข้อมูลที่สามารถอ่านได้เกี่ยวกับผู้ใช้หรือการอนุญาตที่ได้รับ

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

นี่คือตัวอย่างของโทเค็น Opaque:

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

ข้อดี:

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

ข้อเสีย:

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

JWT คืออะไร?#

ในทางตรงกันข้ามกับโทเค็น Opaque, JWT (JSON Web Token) เป็นโทเค็นที่ประกอบด้วยข้อมูลที่สามารถอ่านได้ในลักษณะที่มีโครงสร้างและอ่านง่าย

JWT ประกอบด้วย 3 ส่วน: header, payload, และ signature ซึ่งแต่ละส่วนถูกเข้ารหัสด้วย Base64URL

นี่คือตัวอย่างของ JWT:

• header มีข้อมูลเกี่ยวกับประเภทของโทเค็นและอัลกอริธึ่มที่ใช้สำหรับการลงนาม เช่น {"alg": "HS256", "typ": "JWT"}
• ส่วน payload ประกอบด้วย claims—ข้อมูลเกี่ยวกับผู้ใช้หรือการอนุญาต—เช่น ID ผู้ใช้, เวลาหมดอายุ, และขอบเขต เนื่องจากข้อมูลนี้ถูกเข้ารหัสแต่ไม่ได้ถูกเข้ารหัสแบบเข้มงวด ทุกคนที่มีโทเค็นสามารถถอดรหัสข้อมูล claims ได้ แต่ว่าพวกเขาไม่สามารถเปลี่ยนแปลงได้โดยไม่ทำให้ลายเซ็นต์เป็นโมฆะ ตามข้อกำหนดของเซิร์ฟเวอร์การอนุญาต เราสามารถรวม claims ต่าง ๆ ใน payload ได้ ซึ่งให้ธรรมชาติที่เป็นเอกเทศของโทเค็น เช่น {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}
• signature เกิดจากการรวม header, payload, และคีย์ลับโดยใช้อัลกอริธึมที่ระบุไว้ ลายเซ็นต์นี้ถูกใช้เพื่อยืนยันความสมบูรณ์ของโทเค็นและรับรองว่าไม่ได้ถูกดัดแปลง

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

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

ข้อดี:

• ไม่ต้องเก็บสถานะ: JWTs เป็นโทเค็นแบบเอกเทศและไม่ต้องการการเก็บสถานะในเซิร์ฟเวอร์เพื่อยืนยันความถูกต้อง
• การทำงานร่วมกันข้ามบริการ: JWTs สามารถแชร์และตรวจสอบความถูกต้องได้ง่าย ๆ ข้ามบริการต่าง ๆ ทำให้พวกมันเป็นทางเลือกที่ดีสำหรับระบบที่มีการกระจายตัว
• สามารถขยายได้: payload ของ JWTs สามารถประกอบด้วย claims แบบกำหนดเอง ซึ่งอนุญาตให้มีการอนุญาตและการแบ่งปันข้อมูลที่ยืดหยุ่น
• มาตรฐาน: โทเค็น JWTs ปฏิบัติตามมาตรฐานที่มีการกำหนดไว้อย่างดี (RFC 7519) ทำให้ได้รับการสนับสนุนและทำงานร่วมกันได้อย่างกว้างขวาง

ข้อเสีย:

• การเปิดเผย: claims ใน JWT สามารถมองเห็นได้โดยทุกคนที่สามารถเข้าถึงโทเค็นได้ ดังนั้นจึงไม่ควรรวมข้อมูลที่ละเอียดอ่อนใน payload
• ขนาดใหญ่: JWTs สามารถมีขนาดใหญ่กว่าโทเค็น Opaque เนื่องจากข้อมูลเพิ่มเติมที่พวกมันพกพา ซึ่งสามารถส่งผลกระทบต่อประสิทธิภาพและการจัดการที่เก็บข้อมูล claims ในโทเค็น JWTs ควรได้รับการลดจำนวนให้น้อยที่สุดเพื่อลดขนาดโทเค็น
• ความซับซ้อนในการยกเลิก: เนื่องจาก JWTs ไม่ต้องเก็บสถานะ พวกมันมักจะมีอายุการใช้งานสั้น และไม่มีกลไกในตัวสำหรับการยกเลิกโทเค็นก่อนที่พวกมันจะหมดอายุ หมายความว่าโทเค็นที่ถูกเจาะรูรั่วอาจจะยังคงถูกต้องจนกว่าจะหมดอายุ

การตรวจสอบความถูกต้องของโทเค็นการเข้าถึง Opaque#

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

1. ไคลเอ็นต์ขอโทเค็นการเข้าถึงจากเซิร์ฟเวอร์การอนุญาต
2. เซิร์ฟเวอร์การอนุญาตออกโทเค็น Opaque
3. ไคลเอ็นต์ส่งคำขอเข้าถึงทรัพยากรพร้อมกับโทเค็น Opaque ในส่วนหัว
4. ผู้ให้บริการทรัพยากรส่งคำขอตรวจสอบโทเค็นไปยังเซิร์ฟเวอร์การอนุญาตเพื่อตรวจสอบความถูกต้องของโทเค็น
5. เซิร์ฟเวอร์การอนุญาตตอบกลับด้วยข้อมูลโทเค็น

การตรวจสอบความถูกต้องของโทเค็นการเข้าถึง JWT (ออฟไลน์)#

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

0. ผู้ให้บริการทรัพยากรนำคีย์สาธารณะของเซิร์ฟเวอร์การอนุญาตมาจากจุดค้นพบของ OIDC คีย์สาธารณะนี้ถูกใช้เพื่อตรวจสอบลายเซ็นต์ของโทเค็นและรับรองว่ามันไม่ได้ถูกดัดแปลง
1. ไคลเอ็นต์ขอโทเค็นการเข้าถึงจากเซิร์ฟเวอร์การอนุญาต
2. เซิร์ฟเวอร์การอนุญาตออกโทเค็น JWT
3. ไคลเอ็นต์ส่งคำขอเข้าถึงทรัพยากรพร้อมกับโทเค็น JWT ในส่วนหัว
4. ผู้ให้บริการทรัพยากรถอดรหัสและตรวจสอบความถูกต้องของโทเค็น JWT โดยใช้คีย์สาธารณะที่ได้รับจากเซิร์ฟเวอร์การอนุญาต
5. ผู้ให้บริการทรัพยากรอนุญาตให้เข้าถึงตามความถูกต้องของโทเค็น

กรณีการใช้งานใน OIDC#

ในบริบทของ OIDC (OpenID Connect), โทเค็น Opaque และ JWTs ทำหน้าที่แตกต่างกันและถูกใช้ในสถานการณ์ที่แตกต่างกัน

โทเค็น Opaque#

1. การดึงข้อมูลโปรไฟล์ผู้ใช้:

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

2. การแลกเปลี่ยนโทเค็นรีเฟรช:

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

JWTs#

1. โทเค็น ID:

ใน OIDC, โทเค็น ID เป็น JWT ที่ประกอบด้วยข้อมูลผู้ใช้และถูกใช้ในการรับรองตัวตนของผู้ใช้ มักจะถูกออกพร้อมกับโทเค็นการเข้าถึง โทเค็น ID ช่วยให้ไคลเอ็นต์ยืนยันตัวตนของผู้ใช้ได้ ตัวอย่างเช่น:

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

2. การเข้าถึงทรัพยากร API:

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

ผู้ให้บริการทรัพยากรสามารถตรวจสอบคำขอโดยการตรวจสอบ claims:

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

สรุป#

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

ค้นพบคุณลักษณะของโทเค็นการเข้าถึงเพิ่มเติมใน Logto:

• ใช้ RBAC เพื่อปกป้อง API ของคุณ
• โทเค็นการเข้าถึงองค์กร
• Custom JWT claims