> ## 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. Enquanto o [login com passkey](https://docs.lerian.studio/pt/platform/access-manager/features/passkeys/overview.md) está ativado, o Access Manager recusa configurar um provedor de SSO. > [!NOTE] > > 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 endereço de email, como descrito em [Resolução do tenant](#tenant-resolution). 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, continua para a [verificação da MFA](https://docs.lerian.studio/pt/platform/access-manager/features/mfa/overview) ou responde [`AUT-0019`](https://docs.lerian.studio/pt/platform/access-manager/features/mfa/api#enroll-a-required-method) quando o usuário não tem nenhum método de MFA e a organização exige um. 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 *** Cada tenant é uma organização do Caradhras. O SSO usa dois campos dessa organização: * `domain` é o domínio de email dos usuários do tenant, como `example.com`. O Auth recusa a entrada por SSO quando o domínio do email do usuário é diferente do `domain` do tenant. * `domainHome` marca a única organização em que as pessoas desse domínio recebem a conta quando entram por SSO pela primeira vez. Cada domínio tem no máximo uma organização principal. Uma pessoa com contas em vários tenants entra no tenant padrão dela. Se a pessoa não tiver um tenant padrão, o Auth escolhe um. No Lerian Cloud, a Lerian define esses campos para você. Em um deploy BYOC, defina-os como descrito em [Requisitos de deploy do SSO](https://docs.lerian.studio/pt/platform/access-manager/features/sso/deployment.md). Um deploy BYOC pode usar uma organização fixa, definida com `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION`. O Auth então não compara o domínio do email com a organização. A descoberta não revela identificadores do tenant. Um email desconhecido recebe a mesma resposta geral que um tenant sem SSO. ## 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 *** > [card] [Configure o SSO no Console](https://docs.lerian.studio/pt/platform/access-manager/features/sso/console.md) > > Teste, salve, revise e remova o provedor do tenant. > [card] [Requisitos de deploy do SSO](https://docs.lerian.studio/pt/platform/access-manager/features/sso/deployment.md) > > Configure URLs de callback, o roteamento público do Auth e a resolução do tenant. > [card] [Autenticação multifator](https://docs.lerian.studio/pt/platform/access-manager/features/mfa/overview) > > Adicione uma segunda etapa de verificação depois do SSO. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.