> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Login único
> Permita que os usuários entrem em um workspace Lerian pelo Google, Microsoft Entra ID, Okta ou outro provedor OpenID Connect.
O login único (SSO) permite que um provedor de identidade externo autentique os usuários de um workspace Lerian. O Access Manager resolve o tenant do usuário, redireciona o navegador ao provedor e troca o código de autorização do provedor por tokens de acesso da Lerian.
O SSO se aplica à entrada de usuários. Aplicações de máquina a máquina continuam usando credenciais de cliente.
## Provedores compatíveis
***
| Provedor | Configuração |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Google** | ID do cliente OAuth, segredo do cliente e URL de callback da Lerian. |
| **Microsoft Entra ID** | ID do cliente OAuth, segredo do cliente e URL de callback da Lerian. A API identifica esse provedor como `AzureAD`. |
| **Okta** | ID do cliente OAuth, segredo do cliente, domínio da Okta e URL de callback da Lerian. |
| **OpenID Connect personalizado** | ID do cliente, segredo do cliente, escopos opcionais, URL de callback da Lerian e uma URL de issuer ou endpoints explícitos do provedor. |
O Access Manager aceita um provedor de SSO ativo por tenant. Configurar outro provedor substitui a configuração atual.
Este contrato de SSO usa OAuth 2.0 e OpenID Connect. Ele não configura um provedor SAML.
## Como funciona a entrada
***
1. O Console solicita o endereço de email do usuário.
2. O Auth resolve o tenant a partir do domínio do email usando uma tag da organização com o prefixo `domain:`, como `domain:example.com`, ou usa a organização fixa configurada por `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` em um deploy BYOC de tenant único. Depois, retorna o método de entrada disponível.
3. O Console cria um desafio PKCE S256.
4. O Auth redireciona o navegador ao provedor de identidade configurado.
5. O provedor autentica o usuário e retorna um código de autorização à URL de callback do Console.
6. O Console envia o código, o state e o verificador PKCE ao Auth.
7. O Auth verifica o fluxo e a identidade de email retornada.
8. O Auth retorna tokens de acesso da Lerian ou continua para a [verificação da MFA](/pt/platform/access-manager/features/mfa/overview).
O Auth verifica se o email retornado pelo provedor pertence ao mesmo tenant que iniciou o fluxo. Ele recusa a entrada quando o email está ausente ou é resolvido para outro tenant.
## Resolução do tenant
***
Um deploy BYOC single-tenant pode usar uma organização fixa. Não combine SSO com organização fixa e multi-tenancy.
A descoberta não revela identificadores do tenant. Um email desconhecido recebe a mesma resposta geral que um tenant sem SSO.
## Política de entrada com senha
***
Um tenant pode permitir ou desabilitar a entrada com senha local pela API do Identity.
O Console não expõe um controle separado para a política de senha. Quando você configura o primeiro provedor de SSO no Console, a entrada com senha continua disponível até a primeira entrada bem-sucedida com SSO. Depois, o Auth desabilita a entrada com senha local para esse tenant.
As integrações pela API podem definir a política de senha explicitamente quando precisam de outra transição:
* Desabilitar a entrada com senha logo depois que o provedor for configurado.
* Manter a entrada com senha disponível junto com o SSO.
Teste o SSO antes de desabilitar a entrada com senha local. Um segredo do cliente, issuer, domínio ou URL de callback inválido pode impedir que todos os usuários entrem.
## Validação da configuração
***
Rode a validação de preflight antes de salvar um provedor. O preflight não muda a configuração do tenant.
Ele verifica:
* os campos obrigatórios.
* a descoberta do OpenID Connect quando o provedor usa uma URL de issuer.
* a validação explícita dos endpoints quando a API fornece URLs de autorização, token e informações do usuário.
* as credenciais do cliente.
* a URL de callback.
* os endpoints resolvidos de autorização, token e informações do usuário.
A Okta nem sempre consegue confirmar o cadastro do callback pelo preflight. Cadastre a URL de callback na Okta antes de habilitar o provedor.
## Próximos passos
***
Teste, salve, revise e remova o provedor do tenant.
Configure URLs de callback, o roteamento público do Auth e a resolução do tenant.
Adicione uma segunda etapa de verificação depois do SSO.