JWT vs การยืนยันตัวตนแบบ Session

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

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

มาพูดถึง การยืนยันตัวตนแบบ Session-based และ การยืนยันตัวตนแบบ JWT (JSON Web Tokens) สองวิธีที่ได้รับความนิยมในการเก็บสถานะการยืนยันตัวตน แต่ละวิธีมีข้อดีและการเปรียบเทียบเฉพาะตัว การเลือกระหว่างพวกเขาขึ้นอยู่กับความต้องการเฉพาะของแอปพลิเคชันของคุณ หากคุณกำลังตัดสินใจระหว่างสองสิ่งนี้ คู่มือนี้จะช่วยคุณได้

การยืนยันตัวตนแบบ Session-based คืออะไร?#

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

การทำงานของการยืนยันตัวตนแบบ Session-based#

การสร้างเซสชัน

1. ผู้ใช้ยืนยันตัวตนและให้ข้อมูลประจำตัวบางอย่าง (เช่น อีเมลและรหัสผ่าน)
2. หากข้อมูลประจำตัวถูกต้อง เซิร์ฟเวอร์จะสร้างบันทึกถาวรที่แสดงถึง เซสชัน นั้น เซสชันจะรวมข้อมูลต่างๆ เช่น สตริงสุ่ม ตัวระบุผู้ใช้ เวลาเริ่มต้นเซสชัน เวลาหมดอายุเซสชัน เป็นต้น
3. SessionID จะถูกเก็บใน ฐานข้อมูล และส่งคืนไปยัง ลูกค้า ของผู้ใช้ในรูปแบบของ คุกกี้

การยืนยันเซสชัน

1. กระบวนการอาจส่งได้ด้วยตนเองโดยผู้ใช้ (เช่น คลิกลิงก์ รีเฟรชหน้า) หรืออัตโนมัติโดยลูกค้า (เช่น ระหว่างการโหลดหน้าครั้งแรกหรือผ่านการเรียก API ด้วย SessionID)
2. ทุกคำขอที่ส่งจะเป็นคำขอ HTTP จาก ลูกค้า ที่มี คุกกี้เซสชัน ไปยัง เซิร์ฟเวอร์
3. เซิร์ฟเวอร์จะยืนยัน SessionID โดยการปรึกษาข้อมูลเซสชันที่เก็บไว้ที่เซิร์ฟเวอร์
4. ถ้า valid, server process คำขอและอนุญาตให้ผู้ใช้เข้าถึง

การเพิกถอนเซสชันทำอย่างไร?#

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

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

ข้อดีของการยืนยันตัวตนแบบ Session-based#

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

ข้อเสียของการยืนยันตัวตนแบบ Session-based#

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

การยืนยันตัวตนแบบ JWT คืออะไร?#

JSON Web Tokens (JWTs) ใช้วิธีที่แตกต่างโดยฝังข้อมูลผู้ใช้ที่เกี่ยวข้องทั้งหมดลงในโทเค็น โดยใช้ JSON object แตกต่างจากวิธีแบบ session-based, JWTs จะมีคุณสมบัติที่ stateless, หมายความว่า เซิร์ฟเวอร์ไม่จัดการบันทึกการยืนยันตัวตน

การทำงานของการยืนยันตัวตนแบบ JWT#

JWT ประกอบด้วยสามส่วน: header, payload, และ signature.

• header ประกอบด้วยอัลกอริทึมการเซ็น (ตัวอย่าง, HS256) และประเภทของโทเค็น (JWT).
• payload ประกอบด้วย claims หลัก เช่น ตัวตนผู้ใช้ บทบาทผู้ใช้และเวลาหมดอายุ
• signature ใช้คีย์ในการเซ็น header และ payload เพื่อให้สามารตรวจสอบได้ว่าสามารถถูกแก้ไขได้หรือไม่

การออกโทเค็น JWT

1. ลูกค้าส่งข้อมูลประจำตัวผู้ใช้ไปที่ เซิร์ฟเวอร์ยืนยันตัวตน (identity provider สากลมีประโยชน์โดยเฉพาะสำหรับการจัดการการเข้าถึงผ่านโดเมนที่หลากหลาย)
2. เมื่อยืนยันตัวตนสำเร็จ เซิร์ฟเวอร์จะสร้าง JWT ที่รวม header, payload และ signature
3. AuthServer ส่งโทเค็นที่ออกให้กับ Client ลูกค้าเก็บ JWT (เช่น ในคุกกี้, localStorage หรือ sessionStorage)

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

การยืนยันโทเค็น

1. สำหรับการเรียก API ข้อความ ลูกค้าส่ง JWT ใน Authorization header (Bearer <token>)
2. เซิร์ฟเวอร์จะตรวจสอบลายเซ็นของ JWT โดยใช้คีย์ลับหรือคีย์สาธารณะและตรวจสอบ claims (เช่น หมดอายุ, issuer)
3. ถ้าโทเค็นถูกต้อง เซิร์ฟเวอร์จะอนุญาตให้ลูกค้าเข้าถึงทรัพยากรที่ต้องการ

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

การเพิกถอน JWT ทำอย่างไร?#

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

การเพิกถอน JWT (JSON Web Token) เป็นเรื่องที่ท้าทายกว่าในแบบ session-based เนื่องจาก JWTs ไม่มีสถานะและไม่สามารถเพิกถอนได้เมื่อออกเว้นแต่ว่ามีการใช้งานกลอุบายเฉพาะ วิธีที่พบทั่วไป ได้แก่:

• เวลาหมดอายุสั้น: กำหนด claim exp ให้สั้น (เช่น 15 นาที) สำหรับ JWT เมื่อหมดอายุแล้ว ผู้ใช้จะต้องยืนยันตัวตนซ้ำ นี้จะลดความเสี่ยงถ้าโทเค็นถูกละเมิด เนื่องจากผู้ร้ายสามารถใช้งานได้เพียงช่วงเวลาสั้น สำหรับการรักษาประสบการณ์ของผู้ใช้ที่สมบูรณ์ เราสามารถใช้ refresh token เพื่อลดความไม่สะดวกในการยืนยันตัวตนซ้ำ
• บัญชีดำโทเค็น: สำหรับกรณีที่สำคัญ (เช่น การออกจากระบบ, การเปลี่ยนรหัสผ่าน), เก็บรายการโทเค็นที่ถูกเพิกถอนไว้ในบัญชีดำ เซิร์ฟเวอร์จะตรวจสอบโทเค็นที่เข้ามากับบัญชีดำนี้และปฏิเสธการจับคู่ทั้งหมด แม้ว่าจะเป็นประโยชน์แต่ก็จำเป็นต้องติดตามโทเค็นที่ถูกเพิกถอน ซึ่งขัดกับลักษณะไม่มีสถานะของ JWT และอาจไม่มีประสิทธิภาพเมื่อลิสโตเติบโตใหญ่เกินไป
• จุดสิ้นสุดการเพิกถอน: แนะนำจุดสิ้นสุดการเพิกถอนใน เซิร์ฟเวอร์การอนุญาต ที่โทเค็น (เช่น refresh tokens) สามารถทำให้ไม่สามารถใช้งานได้ เมื่อตั้งค่า refresh token เป็นเพิกถอนแล้ว โทเค็นการเข้าถึงใดๆที่ออกมาจากนั้นจะไม่สามารถต่ออายุได้อีกต่อไป วิธีนี้ทำงานได้ดีใน OAuth2 flows.

ข้อดีของการยืนยันตัวตนแบบ JWT#

• รวดเร็วและมีข้อมูลมากขึ้น: การที่ JWTs เป็น self-contained ทำให้การตรวจสอบในฝั่งลูกค้าเร็วและมีประสิทธิภาพมากขึ้นโดยไม่ต้องมีกระบวนการเซิร์ฟเวอร์ พวกเขายังสามารถรวม claims ที่กำหนดเอง (เช่น บทบาทผู้ใช้หรือข้อมูลที่เกี่ยวข้อง) ภายในโทเค็น ทำให้เซิร์ฟเวอร์สามารถตรวจสอบบทบาทโดยไม่ต้องมีการเขียนไปรายสัตว์
• เสริมความปลอดภัย: JWTs ใช้เทคนิคการเซ็นและการเข้ารหัส ทำให้การโจมตีมีความยากมากขึ้น。
• การสนับสนุนข้ามโดเมน: JWTs สมบูรณ์แบบสำหรับ Single Sign-On (SSO) และการยืนยันตัวตนข้ามโดเมน พวกเขาอนุญาตให้ผู้ใช้ยืนยันตัวตนข้ามโดเมนหรือบริการหลายรายการด้วยโทเค็นเหมือนกัน
• เหมาะสำหรับมือถือ: JWTs ทำงานได้ดีกับแอปพลิเคชันมือถือที่ต้องการการยืนยันตัวตนแบบไม่มีสถานะ โทเค็นสามารถเก็บไว้ในฝั่งลูกค้าและส่งกับแต่ละคำขอ ทำให้มีประสิทธิภาพและใช้งานง่ายขึ้น

ข้อเสียของการยืนยันตัวตนแบบ JWT#

• JWT ไม่ถูกอัปเดตในลักษณะเรียลไทม์

  เมื่อลงนามใน JWT แล้ว ไม่สามารถเพิกถอนหรืออัปเดตได้ และจะถือว่า valid ตราบที่ signature ยัง valid และยังไม่หมดอายุ。

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

• ปัญหาการเพิกถอนหลายอุปกรณ์

  ไม่สามารถตรวจสอบ JWTs ทั้งหมดที่ออกไปก่อนที่พวกมันจะหมดอายุเพื่อดำเนินการเพิกถอนผู้ใช้อุปกรณ์ทุกเครื่อง ในขณะที่ทางทฤษฎีสามารถเพิกถอนคีย์เซ็นเพื่อทำให้ JWTs ไม่ valid แต่ก็จะทำให้ JWTs ที่ใช้คีย์นั้นทั้งหมดกลายเป็น invalid การจัดการคีย์แคชจะทำให้วิธีการนี้เป็นไปไม่ได้สำหรับการดำเนินการเพิกถอนผู้ใช้อย่างง่ายๆ

ตัวให้บริการข้อมูลตัวตนอาจมีโซลูชันที่สร้างเสร็จให้สำหรับปัญหา JWT เหล่านี้ ค้นหารายละเอียดเพิ่มเติมใน "Best Practices to Enhance the JWT Authentication Experience.”

อะไรคือความแตกต่างระหว่าง JWT และ Session?#

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

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

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

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

Session และ JWT: การเลือกวิธีที่เหมาะสม#

วิธีการยืนยันตัวตนของคุณควรตรงกับสถาปัตยกรรมของแอปของคุณและความต้องการเฉพาะ นี่คือคำแนะนำด่วนที่จะช่วยคุณตัดสินใจ:

เมื่อใช้การยืนยันตัวตนแบบ Session-based#

การยืนยันตัวตนแบบ Session-based ทำได้ดีที่สุดเมื่อคุณต้องการการควบคุมเซสชันแบบเรียลไทม์, ต้องการการจัดการศูนย์กลาง, หรือความสามารถในการขยายไม่ได้เป็นข้อกังวลหลัก นี่คือที่ที่มันเฉิดฉาย:

• แอปพลิเคชันเว็บที่มีเซสชันถาวร

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

• แอปพลิเคชันที่ต้องการการควบคุมเซสชันแบบเรียลไทม์

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

• ระบบเซิร์ฟเวอร์เดียวหรือขนาดเล็ก

  เครื่องมือภายในหรือแอปพลิเคชันขนาดเล็กที่ไม่มีความต้องการขยายอย่างหนักเพลินเพลินกับการจัดการเซสชันอย่างง่ายดายเพื่อความสะดวกในการใช้งานและความเชื่อถือได้

เมื่อใช้การยืนยันตัวตนแบบ JWT#

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

• Single Sign-On (SSO)

  JWTs สมบูรณ์แบบสำหรับ Single Sign-On, ช่วยให้ผู้ใช้ยืนยันตัวตนเพียงครั้งเดียวและเข้าถึงหลายบริการหรือแอปพลิเคชันด้วยโทเค็นเดียวกัน แชร์คำอธิบายละเอียดเกี่ยวกับ ประวัติการเชื่อมต่อกับแอปในคลาวด์โดยใช้ OAuth 2.0 และ OIDC, ด้วยรูปแบบ JWT สำหรับทั้ง โทเค็นการเข้าถึง และ โทเค็นประจำตัว

• แอปพลิเคชันมือถือ

  แอปมือถือมักจะเลือกใช้ JWTs สำหรับการยืนยันตัวตนเนื่องจากสามารถเก็บโทเค็นได้อย่างปลอดภัยบนอุปกรณ์และส่งกับคำขอ API แต่ละรายการ ค้นหาเพิ่มเติมเกี่ยวกับการรวมอย่างรวดเร็วของการยืนยันตัวตนแบบ JWT สำหรับ Android / iOS

• สถาปัตยกรรม microservices

  ในสภาพแวดล้อม microservices, JWTs ช่วยให้แต่ละบริการสามารถยืนยันท่าน Tag ได้อย่างอิสระโดยไม่ต้องพึ่งพาร้านค้าเซสชันศูนย์กลาง, รับประกันความสามารถในการขยายและประสิทธิภาพ

• การยืนยันตัวตนข้ามโดเมน

  JWTs เชี่ยวชาญในสถานการณ์ที่เกี่ยวข้องกับโดเมนหรือซับโดเมนหลายรายการ (เช่น api.example.com, dashboard.example.com, และ docs.example.com) แตกต่างจากคุกกี้, JWTs อนุยาตให้การยืนยันตัวตนข้ามโดเมนโดยไม่มีข้อจำกัดพิเศษ

• APIs และบริการเว็บ

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

แนวปฏิบัติที่ดีที่สุดเพื่อปรับปรุงประสบการณ์การยืนยันตัวตนแบบ JWT#

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

การจัดการปัญหาการออกจากระบบของผู้ใช้ด้วย JWT#

ปัญหาที่พบบ่อยกับการยืนยันตัวตนแบบ JWT คือการทำให้ความประสบการณ์ในการออกจากระบบของผู้ใช้อย่างเหมาะสม Logto ง่ายสุดๆกับ SDK ที่มีอยู่

• โดยการล้างโทเค็นและเซสชันในเครื่องในฝั่งลูกค้าและนำผู้ใช้ไปที่ end session endpoint ของ Logto, คุณสามารถยกเลิกเซสชันบนแอปพลิเคชันของลูกค้าและเซิร์ฟเวอร์ได้อย่างง่ายดาย
• นอกจากนี้ Logto สนับสนุน back-channel logout, ทำให้ AuthServer สามารถแจ้งเตือนแอปพลิเคชันลูกค้าทั้งหมดที่แชร์เซสชันเดียวกันเมื่อผู้ใช้ออกจากระบบ

นี้ทำให้มั่นใจในการจัดการเซสชันที่สม่ำเสมอและปลอดภัยในระบบของคุณ เรียนรู้เพิ่มเติมเกี่ยวกับกลไกการออกจากระบบและวิธีการประยุกต์ใช้การออกจากระบบ

การจัดการการเปลี่ยนแปลงสิทธิ์ผู้ใช้#

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

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

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

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