Skip to main content
Auth é o serviço de acesso em tempo de execução do Access Manager. Ele fica entre seus produtos Lerian protegidos e o identity provider configurado, dando aos produtos uma única interface para ciclo de vida de tokens, informações de usuário, verificações de permissão, logout e verificação de login com MFA. Use o Auth quando precisar:
  • solicitar access tokens para usuários humanos ou aplicações máquina-a-máquina;
  • renovar um access token expirado;
  • recuperar informações de usuário compatíveis com OIDC;
  • validar se um subject pode executar uma ação sobre um recurso;
  • recuperar as permissões disponíveis para o usuário autenticado;
  • encerrar a sessão de um usuário;
  • iniciar e verificar desafios de MFA durante o login.
O Auth delega os dados de identidade ao identity provider e faz cache de dados de token, permissão e MFA com o Valkey para reduzir chamadas repetidas durante a operação normal.

​
Fluxos principais

O Auth suporta os fluxos de acesso usados pelos produtos e integrações Lerian.
Fluxo conceitual de autenticação e autorização pelo plugin de Auth, incluindo emissão de tokens e verificação de permissões

Figura 1. Fluxo de Autenticação e Autorização

​
Fluxo de autenticação

  1. Requisição de token
    • Usuários humanos autenticam com o grant password.
    • Integrações de serviço autenticam com o grant client_credentials.
    • O Auth encaminha a requisição ao identity provider e retorna o access token, o refresh token e o ID token quando aplicável.
  2. Renovação de token
    • Os clientes trocam um refresh token por um novo access token.
    • O Auth valida o refresh token com o identity provider antes de emitir o novo token.
  3. Validação de token
    • Os produtos protegidos validam bearer tokens antes de aceitar uma requisição.
    • O Auth extrai claims confiáveis do token para identificar o subject e o contexto de tenant.
    • Os resultados da validação podem ser armazenados em cache para reduzir chamadas repetidas ao identity provider.

​
Contexto de organização

Para autorização, o Auth usa a claim JWT owner quando ela está presente e, caso contrário, a organização configurada. O produto que recebe uma requisição autorizada controla seu próprio contexto de dados de tenant e o isolamento do plano de dados. Não infira um fluxo de resolução de tenant entre produtos apenas a partir do Auth. Para a configuração de deployments multi-tenant, siga a documentação do produto correspondente e de multi-tenancy.

​
Fluxo de SSO no navegador

  1. Inicie o fluxo
    • O navegador inicia o SSO pelo Auth com um endereço de e-mail, um provider elegível e um code_challenge PKCE S256. O Auth resolve o tenant no servidor a partir do domínio de e-mail e redireciona o navegador para o identity provider upstream.
  2. Trate o callback
    • O identity provider redireciona o navegador para PLUGIN_AUTH_SSO_CALLBACK_URL. Essa URL de callback absoluta precisa estar registrada na lista de URIs de redirecionamento permitidas da aplicação do identity provider.
    • O Console envia o código de autorização do provedor, o estado do Auth e o codeVerifier PKCE correspondente pelo grant sso_code do Auth. O Auth consome o fluxo uma vez, retransmite o código ao provedor de identidade e retorna o envelope de tokens.
Antes de emitir tokens, o Auth verifica se o e-mail devolvido pelo provedor de identidade é resolvido para o tenant que iniciou o fluxo. Se o e-mail estiver ausente ou for resolvido para outro tenant, o Auth rejeita o login com a mesma falha SSO genérica usada para outros relays recusados. Configure o provider OAuth e a política de SSO do tenant pelo Identity. A URL de callback do Auth precisa corresponder à URI de redirecionamento permitida da aplicação.

​
Fluxo de login com MFA

  1. Desafio necessário
    • Quando o MFA é exigido, o Auth retorna um estado de desafio de MFA em vez de concluir o login imediatamente.
  2. Inicie a entrega do desafio
    • Para MFA por email ou SMS, o cliente envia o token de MFA retornado e o método selecionado para solicitar a entrega do desafio, e o Auth envia o código de desafio por esse método.
    • Um aplicativo TOTP gera o passcode localmente, sem uma solicitação de entrega.
  3. Verificação do desafio
    • O usuário envia o token de MFA e um passcode ou um código de recuperação, não ambos.
    • O Auth verifica o desafio e retorna os access tokens quando a verificação tem sucesso.
  4. Controles de sessão
    • Os desafios de MFA expiram após o TTL configurado.
    • As tentativas falhas são limitadas para proteger a conta contra tentativas repetidas de adivinhação.

​
Fluxo de autorização

  1. Aplicar acesso
    • Um produto protegido pergunta se o subject autenticado pode executar uma ação específica sobre um recurso específico.
    • O Auth avalia a requisição contra as permissões configuradas no Access Manager.
    • Decisões de autorização bem-sucedidas podem ser armazenadas em cache para performance.
  2. Recuperar permissões
    • Um cliente pode recuperar as permissões disponíveis para o usuário autenticado.
    • O Auth retorna as permissões como um mapa de recursos para ações permitidas.

​
Fluxo de informações do usuário

  1. Requisição de perfil
    • O cliente solicita informações de perfil do usuário com um bearer token.
    • O Auth valida o token e recupera os detalhes do usuário no identity provider.
    • O Auth retorna informações de usuário compatíveis com OIDC.

​
Fluxo de logout

  1. Logout do usuário
    • O cliente envia uma requisição de logout com o ID token hint.
    • O Auth invalida a sessão no identity provider.
    • As entradas de cache relacionadas são limpas.

​
Visão geral da API

O Auth expõe APIs para:
  • solicitar access tokens com password ou client_credentials;
  • renovar access tokens;
  • encerrar sessões de usuário;
  • validar permissões de usuário;
  • recuperar informações de usuário;
  • recuperar permissões de usuário;
  • iniciar, concluir e descobrir fluxos de SSO no navegador;
  • iniciar um desafio de MFA;
  • verificar um desafio de login com MFA.
O Auth expõe pontos de entrada com credenciais e operações protegidas. Siga os requisitos de segurança documentados para cada endpoint. Para detalhes técnicos sobre endpoints e uso, consulte a documentação das APIs do Auth.

​
Decisões de permissão

Quando um produto protegido pergunta ao Auth se um subject pode executar uma ação sobre um recurso, o Auth resolve o subject (um usuário humano ou uma aplicação máquina-a-máquina), busca as permissões associadas a ele e retorna uma decisão de autorizado ou negado. Para usuários humanos, o Auth avalia permissões incorporadas aos dados de identidade, incluindo permissões diretas de usuário e roles aplicáveis. Para aplicações máquina-a-máquina, as permissões vêm do conjunto de permissões configurado da aplicação. O Auth não inventa permissões; ele avalia os dados que o Identity gerencia. Para o modelo completo de subject/recurso/ação, exemplos e como as rotas são protegidas, consulte Aplicação em nível de produto. Para inspecionar o que o subject autenticado consegue alcançar, use Recuperar Permissões de Usuário.

​
Armazenamento de dados e cache

O Auth usa dados de política estruturados e entradas de cache para reduzir trabalho repetido:
  • Dados de política armazenam as regras de controle de acesso para usuários, grupos e aplicações.
  • Cache de token armazena os resultados de validação de token.
  • Cache de permissões armazena decisões de autorização bem-sucedidas.
  • Cache de permissões do usuário armazena o mapa de recursos e ações disponíveis para um usuário.
  • Cache de MFA armazena o estado temporário de desafios, contadores de tentativas e o estado de remember-device quando configurado.

​
Testes e confiabilidade

O Auth passa por testes contínuos para manter confiabilidade e segurança. Os testes cobrem:
  • Fluxos de autenticação e validação de token.
  • Aplicação de controle de acesso.
  • Performance e eficiência de cache.
O Auth também executa avaliações de segurança e monitoramento contínuos nesses fluxos.