smart sso
1.0.0
QQ 통신 그룹: 454343484, 769134727
Smart-SSO는 널리 사용되는 SpringBoot 기술을 사용하며 RBAC 권한 설계와 결합된 OAuth2 인증을 기반으로 하여 가볍고 가용성이 높은 단일 지점 인증 및 권한 부여 센터를 만듭니다.
경량: SpringBoot 및 OAuth2 프로토콜을 기반으로 인증 코드 모드를 최소한으로 구현합니다.
단일 지점 종료: 클라이언트 애플리케이션이 토큰을 획득하면 암시적으로 로그아웃 주소를 서버에 전달합니다. 클라이언트 애플리케이션이 종료되도록 작동하면 서버는 원격으로 모든 클라이언트 애플리케이션에 로컬 토큰을 로그아웃하도록 알리고 단일 지점 종료를 완료합니다.
자동 갱신: 만료되면 클라이언트 백엔드가 자동으로 RefreshToken 새로 고침 인터페이스를 호출하고 서버 측 인증서 스텁 에이징을 업데이트하여 만료 시 자동 갱신을 완료합니다.
도메인 간 지원: 서버와 클라이언트는 서로 다른 도메인 이름에서 도메인 간 Single Sign-On 및 종료 메커니즘을 허용합니다.
프런트엔드 및 백엔드 분리: 사용자는 프런트엔드 및 백엔드 분리(쿠키 모드 없음) 아키텍처에서 Single Sign-On 관련 기능을 쉽게 구현할 수 있습니다.
버튼 수준 권한: 서버는 권한을 메뉴와 버튼으로 분류하고 요청 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. 빨간색 실선은 서버에도 자체 클라이언트인 Single Sign-On이 필요하다는 의미로 이해될 수 있습니다.
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-커넥터-자바 | 8.0.28 | 데이터베이스 기반 |
| http클라이언트 | 4.5.14 | 인증코드 인증, 클라이언트 및 서버 통신 |
다음은 몇 가지 일반적인 SSO 인증 방법을 비교한 것입니다.
| 특성 | 전통 토큰 | JWT | OAuth2 |
|---|---|---|---|
| 싱글 사인온(SSO) | 지원하다 | 지원하다 | 지원하다 |
| 단일 출구 | 지원하다 | 달성하기 어렵다 | 지원하다 |
| 사람들을 오프라인으로 쫓아내세요 | 지원하다 | 달성하기 어렵다 | 지원하다 |
| 만료 후 갱신 | 달성하기 어렵다 | 지원하다 | 지원하다 |
| 성능 | 일반적으로 | 높은 | 더 나은 |
| 보안 | 일반적으로 | 더 나은 | 높은 |
| 복잡성 | 일반적으로 | 더 높은 | 높은 |
설명하다:
전통적인 토큰 방식의 경우 그 메커니즘은 비교적 간단합니다. 일반적으로 서버는 임의의 문자열을 토큰으로 생성한 다음 이를 클라이언트와 서버 간에 전달하여 사용자의 신원을 확인합니다. 그러나 이 방법의 단점도 명백하다. 적시성 및 새로 고침 메커니즘이 부족하여 자동 갱신 기능을 구현하기가 어렵습니다. 클라이언트에서 서버로의 사용자 요청은 토큰 확인을 위해 서버를 자주 호출해야 합니다. 그러나 일부 소규모 프로젝트, 특히 성능이나 보안 요구 사항이 특별히 높지 않은 시나리오의 경우 이 방법이 충분히 적합할 수 있습니다.
JWT의 상태 비저장 특성으로 인해 서버는 키만 저장하면 되고 토큰 정보는 저장할 필요가 없으므로 서버에 대한 저장 부담이 줄어듭니다. 그러나 SSO 시나리오에서는 단일 지점 종료 및 사용자 오프라인 추방 기능을 구현하기가 어렵습니다. 이러한 기능은 로그아웃 원격 알림 또는 공유 저장소와 결합된 백엔드 저장소 토큰에 의존해야 하는 경우가 많습니다. JWT의 개념. 이러한 기능은 보안 요구 사항이 매우 높은 일부 프로젝트에 필수적입니다.
OAuth2는 타사 애플리케이션의 인증된 로그인에 자주 사용되며 SSO 시나리오에 완벽하게 적용되지만 구현하기가 상대적으로 어렵습니다. 이는 자연스럽게 토큰의 에이징 및 새로 고침 메커니즘을 가지며 토큰 갱신을 실현할 수 있는 반면, JWT를 완료하려면 이중 토큰 방식으로 개선해야 합니다. OAuth2 인증 및 승인 센터에 접근해야 하는 각 애플리케이션에 대해 해당 서버에 등록하고 키 정보(ClientId, ClientSecret)를 발급해야 합니다. 이 방법으로만 프로세스에 따라 토큰을 얻을 수 있습니다. 이 작업을 통해 사용자 신원(인증코드 획득 단계)과 클라이언트 애플리케이션 신원(accessToken 획득 단계)에 대한 이중 검증이 가능합니다. 인증 및 권한 부여 시스템의 경우 로그인 성공 후 첫 번째 작업은 현재 애플리케이션에서 로그인된 사용자의 권한 정보를 얻는 것입니다. 따라서 서버는 사용자의 클라이언트 애플리케이션마다 별도로 Token을 발급해야 하며, 단순히 얻을 수는 없습니다. 단일 클라이언트 애플리케이션에서 이를 사용하면 인증 및 승인 센터에서 관리하는 모든 애플리케이션 리소스 권한을 얻을 수 있으며 이는 OAuth2의 원래 의도와도 일치합니다.
결론적으로:
Smart-SSO는 OAuth2를 사용하여 구축하기로 결정했습니다. 단점을 보완하기 위해 일부 기능을 세심하게 업그레이드했습니다. 예를 들어 클라이언트 백엔드는 토큰을 캐시하고 토큰을 전달하는 사용자의 요청은 클라이언트 애플리케이션에서 로컬로 확인할 수 있으므로 클라이언트 애플리케이션과 서버 간의 상호 작용이 크게 줄어듭니다. 갱신 메커니즘도 개선되었습니다. 클라이언트의 로컬 토큰이 만료되면 클라이언트의 백엔드는 서버에 대한 새로 고침 토큰 요청을 시작하고 토큰을 다시 생성하여 프런트 엔드에 다시 씁니다. 인증서 스텁을 사용하여 만료 후 자동 갱신 기능을 수행합니다.
