ทำไม JWT ถึงถูกใช้ในบริการ OAuth 2.0 ส่วนใหญ่

OAuth 2.0 เป็นที่นิยมใช้งานอย่างแพร่หลายในปัจจุบัน ในฐานะที่เป็นแกนหลักสำหรับบริการการอนุญาต หนึ่งในหน้าที่หลักของ OAuth 2.0 คือการออก access tokens ให้กับผู้ใช้ เราสังเกตว่าผู้ให้บริการ OAuth หลายรายในตลาดออก access tokens ในรูปแบบ JWT

ในบทความนี้ เราจะมาแนะนำว่า JWT คืออะไรและทำไมมันถึงถูกใช้งานอย่างกว้างขวางในฐานะรูปแบบของ access tokens ที่ออกโดย OAuth 2.0

การแนะนำ JWT#

JWT ย่อมาจาก JSON Web Token และกำหนดโดย RFC 7519 ดังนี้:

JSON Web Token (JWT) เป็นวิธีการที่กระชับและปลอดภัยใน URL ในการนำเสนอการระบุที่ต้องส่งผ่านระหว่างสองฝ่าย

คำจำกัดความนี้ทำให้ชัดเจนว่า JWT คือตั๋วที่ใช้ในการระบุข้อเรียกร้องระหว่างฝ่ายต่างๆ

เนื่องจาก JWT ถูกส่งผ่านระหว่างหลายฝ่าย จึงมีการลงนามเพื่อให้มั่นใจในความสมบูรณ์และความถูกต้องของข้อมูล

JWT ที่ลงนามแล้วมีรูปแบบดังนี้:

มันประกอบด้วยสามส่วนที่แยกออกจากกันโดย .: header, payload และ signature

นี่คือตัวอย่างของ JWT ที่ใช้ในโลกจริง:

คุณสามารถลองถอดรหัสมันที่ https://jwt.io:

ตามที่แสดงในภาพ ส่วน header ของ JWT ประกอบด้วยข้อมูลเกี่ยวกับอัลกอริธึมการลงนามที่ใช้และประเภทของตั๋ว ส่วน payload ประกอบด้วยการระบุที่ JWT ถือและ signature ใช้ในการตรวจสอบความสมบูรณ์ของ JWT

เมื่อเราเข้าใจแล้วว่า JWT คืออะไรและความหมายของแต่ละส่วน เรามาอธิบายว่าทำไมบริการการอนุญาต OAuth จำนวนมากถึงเลือกใช้ JWT เป็น access token ของพวกเขา

ข้อดีของการใช้ JWT#

ความแตกต่างที่สำคัญระหว่าง JWT และ token ที่สร้างขึ้นจาก string แบบสุ่มดั้งเดิมคือ JWT สามารถบรรทุกข้อมูลและสามารถตรวจสอบความถูกต้องได้ผ่านการถอดรหัส ข้อแตกต่างเหล่านี้นำมาซึ่งข้อดีที่สำคัญสองประการ:

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

เมื่อใช้ token แบบ string แบบสุ่มดั้งเดิม กระบวนการตรวจสอบและรับรองจะเป็นดังนี้:

ตามที่แสดงในแผนภาพ เมื่อระบบมีผู้ใช้จำนวนมากและมี Resource Servers ต่างๆ มากมาย มันสามารถทำให้เกิดคำขอการตรวจสอบ token จำนวนมากไปยัง Auth Server

เมื่อเวลาผ่านไป เมื่อระบบเติบโต Auth Server สามารถกลายเป็นคอขวดได้ง่าย นำมาซึ่งความท้าทายต่อความพร้อมใช้งานของบริการโดยรวม

อย่างไรก็ตาม เมื่อ JWT ถูกนำมาใช้ กระบวนการตรวจสอบจะเปลี่ยนไป:

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

ข้อจำกัดของ JWT#

ขณะที่ JWT มอบข้อได้เปรียบที่สำคัญในสถาปัตยกรรมซอฟต์แวร์สมัยใหม่ มันก็มีข้อจำกัดให้นำมาพิจารณา

โหลดข้อมูลที่ง่ายต่อการถูกสอดแนม#

ดังที่กล่าวถึงก่อนหน้านี้ JWT ประกอบด้วยสามส่วน: header,payload, และ signature ส่วนประกอบเหล่านี้ถูกสร้างขึ้นอย่างไร? มาดูจากตัวอย่าง JWT ก่อนหน้าและสาธิตกระบวนการสร้าง JWT:

ตามที่แสดงในโค้ดด้านบน ส่วน header และ payload ของ JWT เพียงแค่ถูกเข้ารหัสเป็นสตริง base64

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

ขณะที่เป็นความจริงที่ payload ของ JWT สามารถปลอมแปลงได้ค่อนข้างง่าย ควรทราบด้วยว่าส่วน signature ของ JWT ไม่สามารถแทนที่ด้วยเนื้อหาปลอมได้ เนื่องจากต้องการกุญแจลับในการลงนาม ดังนั้น หากไม่มี signature ที่ถูกต้อง JWT จะไม่สามารถผ่านการตรวจสอบความถูกต้องได้

ดังนั้นเมื่อใช้ JWT ควรคำนึงถึงสิ่งต่อไปนี้:

1. ใช้ SSL เสมอ: เพื่อให้แน่ใจว่าข้อมูล JWT จะไม่รั่วไหลระหว่างการส่ง เป็นสิ่งสำคัญในการใช้ SSL (Secure Sockets Layer) หรือ TLS (Transport Layer Security) เพื่อเข้ารหัสข้อมูลในระหว่างการส่ง
2. หลีกเลี่ยงการเก็บข้อมูลที่สำคัญ: ไม่แนะนำให้เก็บข้อมูลที่เป็นความสำคัญใน payload ของ JWT payload สามารถถอดรหัสได้ง่าย ดังที่กล่าวถึงก่อนหน้านี้และควรประกอบด้วยการระบุที่ไม่ใช่ความลับที่เกี่ยวข้อง
3. ตรวจสอบ JWT: ก่อนที่จะพึ่งพาข้อมูลที่มีอยู่ใน JWT ควรให้แน่ใจว่ามันได้ผ่านกระบวนการตรวจสอบความถูกต้องและมีความปลอดภัย รวมถึงการตรวจสอบ signature และการตรวจสอบการหมดอายุของ token เพื่อช่วยป้องกันการใช้ token ที่ถูกแก้ไขหรือไม่ได้รับอนุญาต

ยากที่จะยกเลิก#

โดยทั่วไป access token มักจะมีเวลาหมดอายุ หาก access token ถูกแทนด้วย strings แบบสุ่มโดยไม่มีข้อมูลใด ๆ เราสามารถตรวจสอบว่า token ได้ถูกยกเลิกหรือไม่ในระหว่างการตรวจสอบใน Auth Server

สำหรับ JWT เนื่องจาก JWT มีข้อมูลการหมดอายุอยู่ในตัวเอง และการตรวจสอบ JWT ไม่ได้ขึ้นอยู่กับ Auth Server เมื่อ Auth Server ออก access token ในรูปแบบ JWT จะไม่สามารถเปลี่ยนสถานะของ token ได้ในระหว่างการใช้งาน

หลังจากที่ token JWT หมดอายุโดยธรรมชาติ เราสามารถรับ JWT ใหม่จากเซิร์ฟเวอร์การอนุญาตโดยใช้ refresh token (คุณสามารถดู บล็อกของ Logto สำหรับข้อมูลเกี่ยวกับ refresh token)

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

มีวิธีการทั่วไปสองประการที่ใช้เพื่อลดผลกระทบของการยกเลิก token กลางทาง:

1. กำหนดเวลา expire สำหรับ access token ให้สั้นลงแล้วพึ่งพา mecanismo ของ token refresh เพื่อให้รีเฟรชสถานะของ token ได้

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

2. รักษารายการการยกเลิกสำหรับ access tokens และตรวจสอบว่า token อยู่ในรายชื่อนี้หรือไม่ในระหว่างการตรวจสอบทุกครั้ง

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

สรุป#

ในบทความนี้ เราได้ให้บทนำคร่าวๆ เกี่ยวกับ JWT โดยเน้นถึงข้อได้เปรียบและข้อจำกัดต่างๆ ขณะนี้คุณควรมีความเข้าใจลึกซึ้งขึ้นเกี่ยวกับ JWT และสถานการณ์ที่มักถูกใช้งาน โดยถึงแม้ JWT จะมีข้อท้าทาย แต่ข้อดีที่มันนำมาพอใช้งานเป็น token format ในบริการ OAuth 2.0 ย่อมมีน้ำเหนือกว่า Logto ในฐานะบริการการพิสูจน์ตัวตนที่เติบโตอย่างรวดเร็ว ก็นำ JWT มาใช้เป็นรูปแบบสำหรับ access tokens ด้วย ซึ่งทำให้การรวมบริการการพิสูจน์ตัวตนเข้าไปในผลิตภัณฑ์ของคุณอื่นได้ง่ายมาก Logto ได้เปิดตัวบริการ SaaS อย่างเป็นทางการแล้วและคุณสามารถลองใช้ได้ฟรีวันนี้