ไทย

oidc
oauth
jwt
opaque token

โทเค็น Opaque กับ JWT

ทำความเข้าใจถึงความแตกต่างระหว่างโทเค็น Opaque และ JWTs กรณีการใช้งาน และวิธีการตรวจสอบความถูกต้องในระบบที่ใช้ OIDC

Simeng

Developer

8/30/2024

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

ใน 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:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

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

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

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

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

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

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

โทเค็น Opaque

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

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

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

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

JWTs

โทเค็น ID:

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

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

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

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

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

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

สรุป

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

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

ลองใช้ Logto วันนี้

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

JWT คืออะไร?#

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

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

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

โทเค็น Opaque#

JWTs#

สรุป#

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

JWT คืออะไร?#

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

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

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

โทเค็น Opaque#

JWTs#

สรุป#

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

JWT คืออะไร?

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

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

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

โทเค็น Opaque

JWTs

สรุป

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

JWT คืออะไร?

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

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

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

โทเค็น Opaque

JWTs

สรุป