Autenticação no Portal 2
A autenticação confirma quem está usando o Portal 2. A autorização decide quais recursos essa pessoa pode acessar depois de entrar. O Portal separa essas responsabilidades para que o navegador não armazene tokens de acesso e cada serviço valide as permissões no lugar correto.
Esta é uma visão geral. Use as páginas relacionadas para seguir um fluxo de navegador, integrar uma aplicação OAuth ou entender as proteções de sessão.
Neste guia
- Entrar pelo navegador explica as telas de senha, MFA, QR Code, recuperação e SafeID.
- Sessão e segurança do navegador descreve cookies, CSRF, origem, expiração e permissões.
- OAuth e OpenID Connect mostra como uma aplicação externa recebe um código e troca-o por tokens.
- Branding e acesso descreve a marca por tenant e os guards do frontend.
Como as partes colaboram
O navegador conversa com o BFF. O BFF mantém a sessão do navegador e chama o serviço de Identity quando precisa autenticar ou autorizar uma operação. Uma aplicação externa usa o servidor OAuth do Identity e volta ao Portal somente quando a pessoa precisa entrar ou consentir o acesso.
| Componente | Responsabilidade | Não faz |
|---|---|---|
| Portal 2 | Mostra as telas, valida a entrada e controla a navegação. | Não guarda access token ou refresh token no armazenamento do navegador. |
| BFF | Cria e lê a sessão opaca do navegador, aplica origem e CSRF, e concentra os contratos voltados à interface. | Não trata o estado local do Angular como prova de identidade. |
| Identity | Valida credenciais, MFA, clientes OAuth, códigos de autorização e tokens. | Não define quais botões o frontend deve ocultar. |
| Serviço de permissões | Calcula as permissões efetivas por tenant e unidade. | Não substitui a validação de autenticação da sessão. |
Caminho principal no navegador
- A pessoa abre uma rota protegida.
- O
authGuardpede a sessão atual ao BFF. - Sem sessão válida, o Portal guarda apenas uma URL interna de retorno e abre a tela de entrada.
- A pessoa entra com senha e, quando necessário, conclui TOTP ou SafeID.
- O BFF grava uma sessão opaca em cookie
HttpOnlye o Portal consulta os dados mínimos da sessão. - O Portal consulta as permissões efetivas e libera somente os recursos que a pessoa pode usar.
O guard de permissão melhora a experiência ao ocultar ou redirecionar uma rota indisponível. O backend continua sendo a fronteira de segurança: uma pessoa não recebe acesso a um recurso apenas porque alterou o estado do navegador.
Permissões e níveis de acesso
Entrar, recuperar senha, verificar MFA, descobrir o provedor OIDC e iniciar OAuth não exigem uma permissão de negócio. Essas operações validam tenant, sessão, origem, cliente ou prova criptográfica conforme a rota.
Depois da autenticação, o Portal consulta permissões por tenant e unidade. Operações administrativas usam permissões específicas, e ações de plataforma exigem platformAdmin. Consulte Branding e acesso para entender os guards da interface e Sessão e segurança do navegador para o que o BFF valida.
Referências de rota
A referência OpenAPI do Portal 2 é gerada junto com esta documentação. As páginas mais usadas neste guia são:
- Sessão atual — GET /v1/auth/session
- Login do navegador — POST /v1/auth/login
- Iniciar autorização OAuth — GET /v1/oauth/authorize
- Trocar código OAuth — POST /v1/oauth/token
Próximos passos
Se você está implementando ou investigando uma tela de entrada, comece por Entrar pelo navegador. Se está integrando outro produto ao Portal, siga OAuth e OpenID Connect.