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
جيثب: https://github.com/a466350665/smart-sso
كود الجيت: 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 | إطار عمل ORM |
| mysql-connector-java | 8.0.28 | قاعدة البيانات مدفوعة |
| httpclient | 4.5.14 | مصادقة رمز التفويض، واتصالات العميل والخادم |
فيما يلي مقارنة بين العديد من طرق مصادقة SSO الشائعة:
| مميزة | الرمز التقليدي | JWT | OAuth2 |
|---|---|---|---|
| تسجيل الدخول الموحد | يدعم | يدعم | يدعم |
| خروج واحد | يدعم | من الصعب تحقيقه | يدعم |
| طرد الناس حاليا | يدعم | من الصعب تحقيقه | يدعم |
| التجديد بعد انتهاء الصلاحية | من الصعب تحقيقه | يدعم | يدعم |
| أداء | عمومًا | عالي | أحسن |
| حماية | عمومًا | أحسن | عالي |
| تعقيد | عمومًا | أعلى | عالي |
يشرح:
بالنسبة لطريقة التوكن التقليدية، فإن آليتها بسيطة نسبيًا. عادةً ما يقوم الخادم بإنشاء سلسلة عشوائية كرمز ثم يمررها بين العميل والخادم للتحقق من هوية المستخدم. ومع ذلك، فإن عيوب هذه الطريقة واضحة أيضًا. نظرًا لعدم توفر آليات التحديث والتوقيت، يصعب تنفيذ وظيفة التجديد التلقائي. تحتاج طلبات المستخدم من العميل إلى الخادم إلى الاتصال بالخادم بشكل متكرر للتحقق من الرمز المميز. ومع ذلك، بالنسبة لبعض المشاريع الصغيرة، خاصة السيناريوهات التي لا تكون فيها متطلبات الأداء أو الأمان مرتفعة بشكل خاص، قد تكون هذه الطريقة مناسبة بدرجة كافية.
نظرًا لطبيعة JWT عديمة الحالة، يحتاج الخادم فقط إلى تخزين المفتاح ولا يحتاج إلى تخزين معلومات الرمز المميز، وبالتالي تقليل ضغط التخزين على الخادم. ومع ذلك، في سيناريو تسجيل الدخول الموحد، من الصعب تنفيذ وظائف الخروج من نقطة واحدة وطرد الأشخاص دون اتصال بالإنترنت. غالبًا ما تحتاج هذه الوظائف إلى الاعتماد على رمز التخزين الخلفي، جنبًا إلى جنب مع إشعار تسجيل الخروج عن بعد أو التخزين المشترك، والذي يتعارض مع. مفهوم JWT. هذه الميزات لا غنى عنها لبعض المشاريع ذات متطلبات الأمان العالية للغاية.
غالبًا ما يتم استخدام OAuth2 لتسجيل الدخول المصرح به لتطبيقات الطرف الثالث ويتم تكييفه بالكامل مع سيناريوهات تسجيل الدخول الموحد (SSO)، ولكن من الصعب نسبيًا تنفيذه. من الطبيعي أن يكون لديه آلية تقادم وتحديث الرمز المميز، ويمكنه تحقيق تجديد الرمز المميز، بينما يحتاج JWT إلى التحسين إلى طريقة الرمز المزدوج لإكماله. بالنسبة لكل تطبيق يحتاج إلى الوصول إلى مركز المصادقة والترخيص OAuth2، يجب تسجيله على الخادم الخاص به وإصدار المعلومات الأساسية (ClientId، ClientSecret) بهذه الطريقة فقط يمكن الحصول على الرمز المميز وفقًا للعملية. من خلال هذه العملية، يمكن تحقيق التحقق المزدوج من هوية المستخدم (مرحلة الحصول على رمز التفويض) وهوية تطبيق العميل (مرحلة الحصول على AccessToken). بالنسبة لنظام المصادقة والترخيص، فإن المهمة الأولى بعد تسجيل الدخول الناجح هي الحصول على معلومات الإذن للمستخدم الذي قام بتسجيل الدخول في التطبيق الحالي، لذلك، يجب على الخادم إصدار الرمز المميز بشكل منفصل لكل تطبيق عميل للمستخدم، ولا يمكنه الحصول عليه فقط من خلال تطبيق عميل واحد، يمكنك الحصول على جميع أذونات موارد التطبيق التي يديرها مركز المصادقة والترخيص، وهو ما يتوافق أيضًا مع الهدف الأصلي لـ OAuth2.
ختاماً:
قررت Smart-SSO الإنشاء باستخدام OAuth2. ومن أجل تعويض عيوبه، تمت ترقية بعض الوظائف بعناية. على سبيل المثال، تقوم الواجهة الخلفية للعميل بتخزين الرمز المميز مؤقتًا، ويمكن التحقق من طلب المستخدم الذي يحمل الرمز المميز محليًا في تطبيق العميل، مما يقلل بشكل كبير من التفاعل بين تطبيق العميل والخادم. تم أيضًا تحسين آلية التجديد. عندما تنتهي صلاحية الرمز المميز المحلي للعميل، تبدأ الواجهة الخلفية للعميل طلب تحديث الرمز المميز إلى الخادم، وتعيد إنشاء الرمز المميز وتكتبه مرة أخرى إلى الواجهة الأمامية، وفي الوقت نفسه، تعمل على تمديد صلاحية الخادم كعب الشهادة، وبالتالي تحقيق التجديد التلقائي بعد انتهاء الصلاحية.
