> ## 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.
# Inicio de sesión único
> Permite que los usuarios inicien sesión en un espacio de trabajo Lerian mediante Google, Microsoft Entra ID, Okta u otro proveedor OpenID Connect.
El inicio de sesión único (SSO) permite que un proveedor de identidad externo autentique a los usuarios de un espacio de trabajo Lerian. Access Manager resuelve el tenant del usuario, redirige el navegador al proveedor e intercambia el código de autorización del proveedor por tokens de acceso de Lerian.
SSO aplica al inicio de sesión de usuarios. Las aplicaciones de máquina a máquina continúan usando credenciales de cliente.
## Proveedores admitidos
***
| Proveedor | Configuración |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Google** | ID de cliente OAuth, secreto de cliente y URL de callback de Lerian. |
| **Microsoft Entra ID** | ID de cliente OAuth, secreto de cliente y URL de callback de Lerian. La API identifica este proveedor como `AzureAD`. |
| **Okta** | ID de cliente OAuth, secreto de cliente, dominio de Okta y URL de callback de Lerian. |
| **Custom OpenID Connect** | ID de cliente, secreto de cliente, ámbitos opcionales, URL de callback de Lerian y una URL de emisor o endpoints explícitos del proveedor. |
Access Manager admite un proveedor SSO activo por tenant. Configurar otro proveedor reemplaza la configuración actual.
Este contrato SSO usa OAuth 2.0 y OpenID Connect. No configura un proveedor SAML.
## Cómo funciona el inicio de sesión
***
1. Console solicita la dirección de correo electrónico del usuario.
2. Auth resuelve el tenant a partir del dominio del correo electrónico mediante una etiqueta de la organización con el prefijo `domain:`, como `domain:example.com`, o usa la organización fija configurada por `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` en un despliegue BYOC de un solo tenant. Después, devuelve el método de inicio de sesión disponible.
3. Console crea un desafío PKCE S256.
4. Auth redirige el navegador al proveedor de identidad configurado.
5. El proveedor autentica al usuario y devuelve un código de autorización a la URL de callback de Console.
6. Console envía el código, el estado y el verificador PKCE a Auth.
7. Auth verifica el flujo y la identidad de correo electrónico devuelta.
8. Auth devuelve tokens de acceso de Lerian o continúa con la [verificación MFA](/es/platform/access-manager/features/mfa/overview).
Auth verifica que el correo electrónico devuelto por el proveedor pertenezca al mismo tenant que inició el flujo. Rechaza el inicio de sesión cuando falta el correo electrónico o este se resuelve a otro tenant.
## Resolución del tenant
***
Un despliegue BYOC de tenant único puede usar una organización fija. No combines SSO de organización fija con multi-tenancy.
El descubrimiento no revela identificadores del tenant. Un correo electrónico desconocido recibe la misma respuesta general que un tenant sin SSO.
## Política de inicio de sesión con contraseña
***
Un tenant puede permitir o desactivar el inicio de sesión con contraseña local mediante la API de Identity.
Console no expone un control separado de la política de contraseñas. Cuando configuras el primer proveedor SSO en Console, el inicio de sesión con contraseña permanece disponible hasta el primer inicio de sesión SSO exitoso. Auth desactiva entonces el inicio de sesión con contraseña local para ese tenant.
Las integraciones de API pueden definir explícitamente la política de contraseñas cuando necesitan una transición diferente:
* Desactivar el inicio de sesión con contraseña inmediatamente después de configurar el proveedor.
* Mantener disponible el inicio de sesión con contraseña junto con SSO.
Prueba SSO antes de desactivar el inicio de sesión con contraseña local. Un secreto de cliente, emisor, dominio o URL de callback no válidos pueden impedir que todos los usuarios inicien sesión.
## Validación de la configuración
***
Ejecuta la validación previa antes de guardar un proveedor. La validación previa no cambia la configuración del tenant.
Verifica:
* los campos obligatorios.
* el descubrimiento de OpenID Connect cuando el proveedor usa una URL de emisor.
* la validación explícita de endpoints cuando la API proporciona URLs de autorización, token e información de usuario.
* las credenciales de cliente.
* la URL de callback.
* los endpoints resueltos de autorización, token e información de usuario.
Okta no siempre puede confirmar el registro del callback mediante la validación previa. Registra la URL de callback en Okta antes de activar el proveedor.
## Próximos pasos
***
Prueba, guarda, revisa y elimina el proveedor del tenant.
Configura las URLs de callback, el enrutamiento público de Auth y la resolución del tenant.
Agrega un segundo paso de verificación después de SSO.