smart sso
1.0.0
Grupo de comunicação QQ: 454343484, 769134727
O Smart-SSO depende da popular tecnologia SpringBoot e é baseado na autenticação OAuth2 combinada com o design de permissão RBAC para criar um centro de autorização e autenticação de ponto único leve e altamente disponível para você.
Leve: implementação minimalista do modo de código de autorização baseado nos protocolos SpringBoot e OAuth2;
Saída de ponto único: quando o aplicativo cliente obtém o token, ele passa implicitamente seu endereço de logout para o servidor. Quando qualquer aplicativo cliente opera para sair, o servidor notifica remotamente todos os aplicativos cliente para efetuar logout do token local, completando uma saída de ponto único;
Renovação automática: use a política accessToken do protocolo OAuth2. Quando expirado, o back-end do cliente chama automaticamente a interface de atualização refreshToken e atualiza o vencimento do stub do certificado do lado do servidor para concluir a renovação automática após a expiração;
Suporte entre domínios: O servidor e o cliente permitem mecanismos de logon único e saída entre domínios sob diferentes nomes de domínio;
Separação de front-end e back-end: os usuários podem implementar facilmente funções relacionadas ao logon único na arquitetura de separação de front-end e back-end (sem modo cookie);
Permissões em nível de botão: o servidor classifica as permissões em menus e botões e implementa controle em nível de botão de permissão combinando o URI da solicitação e o método de solicitação;
Implantação distribuída: tanto o servidor quanto o cliente oferecem suporte a cenários de implantação de várias instâncias com base no token compartilhado do Redis;
Gitee: https://gitee.com/a466350665/smart-sso
Github: https://github.com/a466350665/smart-sso
Gitcode: 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支持
Observação:
1. A linha sólida vermelha pode ser entendida como o servidor também precisa de login único, que também é seu próprio cliente;
2. A linha pontilhada vermelha indica que, seja o servidor ou o cliente, quando a implantação do cluster é necessária, a dependência da versão do Redis pode ser usada para implementar o compartilhamento de token;
| tecnologia | Versão | ilustrar |
|---|---|---|
| bota de mola | 3.3.4 | Estrutura de contêiner + MVC |
| spring-boot-starter-data-redis | 3.3.4 | Gerenciamento de token de cena distribuído |
| spring-boot-starter-freemarker | 3.3.4 | mecanismo de modelo |
| springfox-boot-starter | 3.0.0 | documento |
| mybatis-plus-spring-boot3-starter | 3.5.7 | Estrutura ORM |
| conector mysql-java | 8.0.28 | Baseado em banco de dados |
| httpclient | 4.5.14 | Autenticação de código de autorização, comunicação cliente e servidor |
A seguir está uma comparação de vários métodos comuns de autenticação SSO:
| característica | Símbolo Tradicional | JWT | OAuth2 |
|---|---|---|---|
| Logon único | apoiar | apoiar | apoiar |
| saída única | apoiar | Difícil de conseguir | apoiar |
| Chute as pessoas off-line | apoiar | Difícil de conseguir | apoiar |
| Renovação após expiração | Difícil de conseguir | apoiar | apoiar |
| desempenho | geralmente | alto | melhorar |
| segurança | geralmente | melhorar | alto |
| complexidade | geralmente | mais alto | alto |
explicar:
Para o método Token tradicional, seu mecanismo é relativamente simples. Normalmente, o servidor gera uma string aleatória como token e a passa entre o cliente e o servidor para verificar a identidade do usuário. No entanto, as deficiências deste método também são óbvias. Devido à falta de pontualidade e mecanismos de atualização, a função de renovação automática é difícil de implementar. As solicitações do usuário do cliente para o servidor precisam ligar frequentemente para o servidor para verificação de token. No entanto, para alguns projetos pequenos, especialmente cenários onde os requisitos de desempenho ou segurança não são particularmente elevados, este método pode ser suficientemente adequado.
Devido à natureza sem estado do JWT, o servidor só precisa armazenar a chave e não precisa armazenar informações do token, reduzindo assim a pressão de armazenamento no servidor. No entanto, no cenário SSO, é difícil implementar as funções de saída de ponto único e colocar as pessoas offline. Essas funções geralmente precisam depender do token de armazenamento de back-end, combinado com notificação remota de logout ou armazenamento compartilhado, o que entra em conflito com o token de armazenamento de back-end. conceito de JWT. Esses recursos são indispensáveis para alguns projetos com requisitos de segurança extremamente elevados.
OAuth2 é frequentemente usado para login autorizado de aplicativos de terceiros e é totalmente adaptado a cenários de SSO, mas é relativamente difícil de implementar. Naturalmente, ele possui o mecanismo de envelhecimento e atualização do token e pode realizar a renovação do token, enquanto o JWT precisa ser aprimorado para um método de token duplo para ser concluído. Para cada aplicação que necessita acessar a central de autenticação e autorização OAuth2, ela deve ser cadastrada em seu servidor e emitir informações chave (ClientId, ClientSecret). Somente desta forma o Token poderá ser obtido de acordo com o processo. Através desta operação, a dupla verificação da identidade do usuário (fase de aquisição do código de autorização) e da identidade do aplicativo cliente (fase de aquisição do accessToken) pode ser alcançada. Para o sistema de autenticação e autorização, a primeira tarefa após o login bem-sucedido é obter as informações de permissão do usuário logado na aplicação atual. Portanto, o servidor deve emitir Token separadamente para cada aplicação cliente do usuário, não podendo apenas obter. a partir de um único token de aplicativo cliente, você pode obter todas as permissões de recursos do aplicativo gerenciadas pelo centro de autenticação e autorização, o que também é consistente com a intenção original do OAuth2.
para concluir:
O Smart-SSO decidiu construir com OAuth2. Para compensar as suas deficiências, algumas funções foram cuidadosamente atualizadas. Por exemplo, o back-end do cliente armazena o token em cache, e a solicitação do usuário que transporta o token pode ser verificada localmente no aplicativo cliente, o que reduz bastante a interação entre o aplicativo cliente e o servidor. O mecanismo de renovação também foi melhorado. Quando o token local do cliente expira, o back-end do cliente inicia uma solicitação de atualizaçãoToken para o servidor, regenera o token e o grava de volta no front-end. stub de certificado, conseguindo assim a renovação automática após a função de expiração.
