smart sso
1.0.0
Группа связи QQ: 454343484, 769134727
Smart-SSO опирается на популярную технологию SpringBoot и основан на аутентификации OAuth2 в сочетании с дизайном разрешений RBAC, что позволяет создать для вас легкий, высокодоступный единый центр аутентификации и авторизации.
Облегченный: минималистичная реализация режима кода авторизации на основе протоколов SpringBoot и OAuth2;
Выход из одной точки: когда клиентское приложение получает токен, оно неявно передает свой адрес выхода на сервер. Когда какое-либо клиентское приложение выполняет выход, сервер удаленно уведомляет все клиентские приложения о необходимости выхода из локального токена, завершая выход из одной точки.
Автоматическое продление: используйте политику accessToken протокола OAuth2. По истечении срока действия серверная часть клиента автоматически вызывает интерфейс обновленияrefreToken и обновляет заглушку сертификата на стороне сервера, чтобы завершить автоматическое продление по истечении срока действия.
Междоменная поддержка: сервер и клиент допускают междоменный механизм единого входа и выхода под разными доменными именами;
Разделение внешней и внутренней частей: пользователи могут легко реализовать функции единого входа в архитектуре разделения внешней и внутренней части (без режима файлов cookie);
Разрешения на уровне кнопок: сервер классифицирует разрешения на меню и кнопки и реализует управление на уровне кнопок разрешений, сопоставляя 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-фреймворк |
| весна-загрузка-стартер-данные-redis | 3.3.4 | Управление токенами распределенной сцены |
| весна-загрузка-стартер-фримаркер | 3.3.4 | шаблонизатор |
| Springfox-загрузочный стартер | 3.0.0 | документ |
| mybatis-plus-spring-boot3-starter | 3.5.7 | ORM-фреймворк |
| MySQL-коннектор-Java | 8.0.28 | Управление базой данных |
| httpклиент | 4.5.14 | Аутентификация кода авторизации, связь клиента и сервера |
Ниже приводится сравнение нескольких распространенных методов аутентификации SSO:
| характеристика | Традиционный жетон | JWT | ОАут2 |
|---|---|---|---|
| Единый вход | поддерживать | поддерживать | поддерживать |
| единственный выход | поддерживать | Трудно достичь | поддерживать |
| Выкидывать людей из сети | поддерживать | Трудно достичь | поддерживать |
| Продление после истечения срока действия | Трудно достичь | поддерживать | поддерживать |
| производительность | в целом | высокий | лучше |
| безопасность | в целом | лучше | высокий |
| сложность | в целом | выше | высокий |
объяснять:
Механизм традиционного метода Token относительно прост. Обычно сервер генерирует случайную строку в качестве токена, а затем передает ее между клиентом и сервером для проверки личности пользователя. Однако недостатки этого метода также очевидны. Из-за отсутствия механизмов своевременности и обновления функцию автоматического продления сложно реализовать. Пользовательские запросы от клиента к серверу требуют частого вызова сервера для проверки токена. Однако для некоторых небольших проектов, особенно сценариев, где требования к производительности или безопасности не особенно высоки, этот метод может подойти.
Из-за того, что JWT не сохраняет состояние, серверу необходимо хранить только ключ и не нужно хранить информацию о токене, что снижает нагрузку на хранилище на сервере. Однако в сценарии единого входа сложно реализовать функции одноточечного выхода и отключения людей от сети. Эти функции часто должны полагаться на токен внутреннего хранилища в сочетании с удаленным уведомлением о выходе из системы или общим хранилищем, что конфликтует с общим хранилищем. концепция JWT. Эти функции незаменимы для некоторых проектов с чрезвычайно высокими требованиями к безопасности.
OAuth2 часто используется для авторизованного входа в сторонние приложения и полностью адаптирован к сценариям единого входа, но его относительно сложно реализовать. Естественно, он имеет механизм устаревания и обновления токена и может реализовывать обновление токена, в то время как для завершения JWT необходимо улучшить до метода двойного токена. Для каждого приложения, которому необходим доступ к центру аутентификации и авторизации OAuth2, оно должно быть зарегистрировано на его сервере и выдать ключевую информацию (ClientId, ClientSecret). Только таким образом можно получить Токен в соответствии с процессом. Благодаря этой операции может быть достигнута двойная проверка личности пользователя (этап получения кода авторизации) и идентификации клиентского приложения (этап получения accessToken). Для системы аутентификации и авторизации первой задачей после успешного входа в систему является получение информации о разрешениях вошедшего в систему пользователя в текущем приложении. Поэтому сервер должен выдавать Токен отдельно для каждого клиентского приложения пользователя и не может просто получить его. Используя один токен клиентского приложения, вы можете получить все разрешения на ресурсы приложения, управляемые центром аутентификации и авторизации, что также соответствует первоначальному замыслу OAuth2.
в заключение:
Smart-SSO решил использовать OAuth2. Чтобы компенсировать недостатки, некоторые функции были тщательно улучшены. Например, серверная часть клиента кэширует токен, а запрос пользователя, содержащий токен, может быть проверен локально в клиентском приложении, что значительно снижает взаимодействие между клиентским приложением и сервером. Механизм продления также был улучшен. Когда срок действия локального токена клиента истекает, серверная часть клиента инициирует запрос обновления токена на сервер, повторно генерирует токен и записывает его обратно во внешний интерфейс. В то же время это продлевает срок действия токена сервера. корешок сертификата, тем самым обеспечивая автоматическое продление после истечения срока действия.
