smart sso
1.0.0
กลุ่มการสื่อสาร QQ: 454343484, 769134727
Smart-SSO อาศัยเทคโนโลยี SpringBoot ยอดนิยมและอิงตามการตรวจสอบสิทธิ์ OAuth2 รวมกับการออกแบบสิทธิ์ RBAC เพื่อสร้างศูนย์การตรวจสอบสิทธิ์และการอนุญาตจุดเดียวที่มีน้ำหนักเบาและพร้อมใช้งานสูงสำหรับคุณ
น้ำหนักเบา: การใช้งานโหมดรหัสการอนุญาตแบบเรียบง่ายโดยใช้โปรโตคอล SpringBoot และ OAuth2
ทางออกจุดเดียว: เมื่อแอปพลิเคชันไคลเอนต์ได้รับโทเค็น จะส่งที่อยู่การออกจากระบบไปยังเซิร์ฟเวอร์โดยปริยาย เมื่อแอปพลิเคชันไคลเอนต์ใด ๆ ทำงานเพื่อออก เซิร์ฟเวอร์จะแจ้งเตือนแอปพลิเคชันไคลเอนต์ทั้งหมดจากระยะไกลให้ออกจากระบบโทเค็นในเครื่อง โดยเสร็จสิ้นการออกจากจุดเดียว
การต่ออายุอัตโนมัติ: ใช้นโยบาย accessToken ของโปรโตคอล OAuth2 เมื่อหมดอายุ แบ็กเอนด์ไคลเอ็นต์จะเรียกอินเทอร์เฟซการรีเฟรช RefreshToken โดยอัตโนมัติ และอัปเดตอายุต้นใบรับรองฝั่งเซิร์ฟเวอร์เพื่อให้การต่ออายุอัตโนมัติเสร็จสมบูรณ์เมื่อหมดอายุ
การสนับสนุนข้ามโดเมน: เซิร์ฟเวอร์และไคลเอนต์อนุญาตให้ใช้กลไกการลงชื่อเข้าและออกครั้งเดียวข้ามโดเมนภายใต้ชื่อโดเมนที่แตกต่างกัน
การแยกส่วนหน้าและส่วนหลัง: ผู้ใช้สามารถใช้ฟังก์ชันที่เกี่ยวข้องกับการลงชื่อเพียงครั้งเดียวได้อย่างง่ายดายภายใต้สถาปัตยกรรมของการแยกส่วนหน้าและส่วนหลัง (ไม่มีโหมดคุกกี้)
สิทธิ์ระดับปุ่ม: เซิร์ฟเวอร์จัดประเภทสิทธิ์เป็นเมนูและปุ่ม และใช้การควบคุมระดับปุ่มสิทธิ์โดยการจับคู่ URI คำขอและวิธีการร้องขอ
การปรับใช้แบบกระจาย: ทั้งเซิร์ฟเวอร์และไคลเอนต์รองรับสถานการณ์การปรับใช้หลายอินสแตนซ์โดยอิงตามโทเค็นที่ใช้ร่วมกันของ Redis
กิติ: https://gitee.com/a466350665/smart-sso
Github: https://github.com/a466350665/smart-sso
รหัส Git: https://gitcode.com/openjoe/smart-sso
smart - sso
├── smart - sso - demo -- 客户端示例
├── smart - sso - demo - h5 -- 前后端分离客户端示例
├── smart - sso - server -- 单点登录权限管理服务端
├── smart - sso - starter -- 依赖装配模块
│ ├── smart - sso - starter - base -- 公用的基础常量、工具、凭证清理机制
│ ├── smart - sso - starter - client -- 客户端依赖包，客户端Token生命周期管理
│ ├── smart - sso - starter - client - redis -- 客户端依赖装配，分布式部署场景redis支持
│ ├── smart - sso - starter - server -- 服务端依赖包，服务端凭证生命周期管理
│ ├── smart - sso - starter - server - redis -- 服务端依赖装配，分布式部署场景redis支持
บันทึก:
1. เส้นทึบสีแดงสามารถเข้าใจได้ เนื่องจากเซิร์ฟเวอร์ยังต้องการการลงชื่อเข้าใช้เพียงครั้งเดียว ซึ่งเป็นไคลเอนต์ของตัวเองด้วย
2. เส้นประสีแดงระบุว่าไม่ว่าจะเป็นเซิร์ฟเวอร์หรือไคลเอนต์ เมื่อจำเป็นต้องมีการปรับใช้คลัสเตอร์ การขึ้นต่อกันของเวอร์ชัน Redis สามารถใช้เพื่อปรับใช้การแชร์โทเค็น
| เทคโนโลยี | เวอร์ชัน | แสดงให้เห็น |
|---|---|---|
| สปริงบูต | 3.3.4 | คอนเทนเนอร์ + เฟรมเวิร์ก MVC |
| spring-boot-starter-data-redis | 3.3.4 | การจัดการโทเค็นฉากแบบกระจาย |
| spring-boot-starter-freemarker | 3.3.4 | เครื่องยนต์แม่แบบ |
| springfox-บูต-สตาร์ทเตอร์ | 3.0.0 | เอกสาร |
| mybatis-plus-spring-boot3-starter | 3.5.7 | กรอบการทำงานออม |
| mysql-เชื่อมต่อ-java | 8.0.28 | ฐานข้อมูลขับเคลื่อน |
| httpclient.php | 4.5.14 | การรับรองความถูกต้องของรหัสอนุญาต การสื่อสารไคลเอนต์และเซิร์ฟเวอร์ |
ต่อไปนี้เป็นการเปรียบเทียบวิธีการตรวจสอบสิทธิ์ SSO ทั่วไปหลายวิธี:
| ลักษณะเฉพาะ | โทเค็นแบบดั้งเดิม | เจดับบลิว | OAuth2 |
|---|---|---|---|
| การลงชื่อเข้าใช้เพียงครั้งเดียว | สนับสนุน | สนับสนุน | สนับสนุน |
| ทางออกเดียว | สนับสนุน | ยากที่จะบรรลุ | สนับสนุน |
| เตะคนออฟไลน์ | สนับสนุน | ยากที่จะบรรลุ | สนับสนุน |
| ต่ออายุหลังจากหมดอายุ | ยากที่จะบรรลุ | สนับสนุน | สนับสนุน |
| ผลงาน | โดยทั่วไป | สูง | ดีกว่า |
| ความปลอดภัย | โดยทั่วไป | ดีกว่า | สูง |
| ความซับซ้อน | โดยทั่วไป | สูงกว่า | สูง |
อธิบาย:
สำหรับวิธี Token แบบดั้งเดิม กลไกของมันค่อนข้างง่าย โดยปกติแล้ว เซิร์ฟเวอร์จะสร้างสตริงสุ่มเป็นโทเค็น แล้วส่งต่อระหว่างไคลเอ็นต์และเซิร์ฟเวอร์เพื่อตรวจสอบตัวตนของผู้ใช้ อย่างไรก็ตามข้อบกพร่องของวิธีนี้ก็ชัดเจนเช่นกัน เนื่องจากขาดกลไกที่ทันเวลาและรีเฟรช ฟังก์ชันการต่ออายุอัตโนมัติจึงดำเนินการได้ยาก คำขอของผู้ใช้จากไคลเอนต์ไปยังเซิร์ฟเวอร์จึงจำเป็นต้องเรียกเซิร์ฟเวอร์บ่อยครั้งเพื่อตรวจสอบโทเค็น อย่างไรก็ตาม สำหรับโครงการขนาดเล็กบางโครงการ โดยเฉพาะอย่างยิ่งสถานการณ์ที่ข้อกำหนดด้านประสิทธิภาพหรือความปลอดภัยไม่สูงเป็นพิเศษ วิธีนี้อาจเหมาะสมเพียงพอ
เนื่องจากลักษณะไร้สัญชาติของ JWT เซิร์ฟเวอร์จึงจำเป็นต้องจัดเก็บคีย์เท่านั้นและไม่จำเป็นต้องจัดเก็บข้อมูลโทเค็น ซึ่งช่วยลดความกดดันในการจัดเก็บข้อมูลบนเซิร์ฟเวอร์ อย่างไรก็ตาม ในสถานการณ์ SSO เป็นเรื่องยากที่จะใช้ฟังก์ชันการออกแบบจุดเดียวและเตะผู้คนแบบออฟไลน์ ฟังก์ชันเหล่านี้มักจะต้องใช้โทเค็นที่เก็บข้อมูลแบ็คเอนด์ รวมกับการแจ้งเตือนระยะไกลจากการออกจากระบบหรือที่เก็บข้อมูลที่ใช้ร่วมกัน ซึ่งขัดแย้งกับ แนวคิดของ JWT คุณสมบัติเหล่านี้ขาดไม่ได้สำหรับบางโปรเจ็กต์ที่มีข้อกำหนดด้านความปลอดภัยที่สูงมาก
OAuth2 มักใช้สำหรับการเข้าสู่ระบบที่ได้รับอนุญาตของแอปพลิเคชันบุคคลที่สาม และได้รับการปรับให้เข้ากับสถานการณ์ SSO อย่างสมบูรณ์ แต่การนำไปใช้ค่อนข้างยาก โดยธรรมชาติแล้วจะมีกลไกการแก่และการรีเฟรชของ Token และสามารถรับรู้ถึงการต่ออายุ Token ได้ ในขณะที่ JWT จำเป็นต้องได้รับการปรับปรุงเป็นวิธี Token แบบคู่จึงจะเสร็จสมบูรณ์ สำหรับแต่ละแอปพลิเคชันที่ต้องการเข้าถึงศูนย์การรับรองความถูกต้องและการอนุญาต OAuth2 จะต้องลงทะเบียนบนเซิร์ฟเวอร์และออกข้อมูลสำคัญ (ClientId, ClientSecret) ด้วยวิธีนี้เท่านั้นที่สามารถรับโทเค็นได้ตามกระบวนการ ด้วยการดำเนินการนี้ จึงสามารถบรรลุการตรวจสอบยืนยันตัวตนผู้ใช้ซ้ำซ้อน (ขั้นตอนการรับรหัสอนุญาต) และการระบุตัวตนแอปพลิเคชันไคลเอนต์ (ขั้นตอนการรับโทเค็นการเข้าถึง) สามารถทำได้ สำหรับระบบการตรวจสอบสิทธิ์และการอนุญาต งานแรกหลังจากการเข้าสู่ระบบสำเร็จคือการรับข้อมูลสิทธิ์ของผู้ใช้ที่เข้าสู่ระบบในแอปพลิเคชันปัจจุบัน ดังนั้น เซิร์ฟเวอร์จะต้องออกโทเค็นแยกต่างหากสำหรับแต่ละแอปพลิเคชันไคลเอนต์ของผู้ใช้ และไม่สามารถรับได้เพียงอย่างเดียว จากแอปพลิเคชันไคลเอนต์เดียว โทเค็น คุณสามารถรับสิทธิ์ทรัพยากรแอปพลิเคชันทั้งหมดที่จัดการโดยศูนย์การรับรองความถูกต้องและการอนุญาตซึ่งสอดคล้องกับเจตนาดั้งเดิมของ OAuth2
สรุปแล้ว:
Smart-SSO ตัดสินใจสร้างด้วย OAuth2 เพื่อชดเชยข้อบกพร่อง ฟังก์ชั่นบางอย่างได้รับการอัพเกรดอย่างระมัดระวัง ตัวอย่างเช่น แบ็กเอนด์ไคลเอ็นต์แคชโทเค็น และคำขอของผู้ใช้ที่มีโทเค็นสามารถตรวจสอบได้ในแอปพลิเคชันไคลเอนต์ ซึ่งช่วยลดการโต้ตอบระหว่างแอปพลิเคชันไคลเอนต์และเซิร์ฟเวอร์ได้อย่างมาก กลไกการต่ออายุยังได้รับการปรับปรุงอีกด้วย เมื่อโทเค็นในเครื่องของลูกค้าหมดอายุ แบ็กเอนด์ของลูกค้าจะเริ่มต้นคำขอ RefreshToken ไปยังเซิร์ฟเวอร์ สร้างโทเค็นใหม่และเขียนกลับไปที่ส่วนหน้า ในเวลาเดียวกัน จะขยายความถูกต้องของเซิร์ฟเวอร์ ต้นขั้วใบรับรอง จึงได้รับการต่ออายุอัตโนมัติหลังจากฟังก์ชันหมดอายุ
