Configuración de Azure AD (OIDC)
Guía paso a paso para configurar el inicio de sesión único con Microsoft Entra ID (Azure AD) utilizando OpenID Connect.
Requisitos previos
- Tenant de Azure AD con acceso de administrador
- Cuenta de administrador de organización en SecureCodingHub
- Dominio de la organización verificado en SecureCodingHub
Paso 1 — Registre una aplicación en Azure AD
Vaya a Azure Portal → Microsoft Entra ID → App registrations → New registration
Nombre: SecureCodingHub SSO
Tipos de cuenta admitidos: Accounts in this organizational directory only
URI de redirección: Web → https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Haga clic en Register
Paso 2 — Cree un secreto de cliente
Vaya a Certificates & secrets → New client secret
Descripción: SecureCodingHub
Caducidad: elija su política (recomendado: 24 meses)
Copie el valor del secreto inmediatamente — solo se muestra una vez
Paso 3 — Anote sus identificadores
Recopile los siguientes valores de su aplicación de Azure AD. Los necesitará en el siguiente paso.
| Ajuste | Dónde encontrarlo |
|---|---|
| Application (Client) ID | Página Overview |
| Directory (Tenant) ID | Página Overview |
| Client Secret | Certificates & secrets |
| URL de descubrimiento | https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
Paso 4 — Configure SSO en SecureCodingHub
Inicie sesión como administrador de organización → Ajustes de SSO
Protocolo: OIDC
Entity ID / Client ID: pegue su Application ID
URL de Discovery / Metadata: pegue su URL de configuración OpenID
Client Secret: pegue el secreto
Activar SSO
Haga clic en Guardar
Paso 5 — Pruebe
Abra una ventana de navegador en modo incógnito/privado
Vaya al inicio de sesión de SecureCodingHub
Introduzca una dirección de correo con el dominio de su organización
Debería ser redirigido al inicio de sesión de Microsoft
Tras la autenticación, debería iniciar sesión en SecureCodingHub
Errores comunes de SAML con Azure AD
Cuando se utiliza SAML con Azure AD en lugar de OIDC, tres modos de fallo concentran la mayoría de los incidentes en producción. El primero es un entity ID no coincidente. Azure AD aceptará cualquier cadena en el campo Identifier de la hoja SSO, pero si no coincide exactamente con el SP Entity ID configurado en SecureCodingHub, la respuesta SAML se rechaza con un error de restricción de audiencia. Copie el identificador directamente desde la página de ajustes SSO de SecureCodingHub, no lo escriba. Las barras al final y los desajustes de protocolo (http frente a https) son fallos silenciosos habituales.
El segundo error es un desajuste en la URI del emisor del claim. Azure AD firma las afirmaciones con la URL de metadatos de federación que publica, y SecureCodingHub valida que el emisor de la respuesta SAML coincida con el emisor de los metadatos. Si cambia de tenant, regenera certificados o copia una URL de metadatos desde otra aplicación, el emisor divergirá y todos los inicios de sesión fallarán con un error de firma no válida. El tercer error es el tamaño del claim de grupos. Azure AD trunca los claims de grupos cuando la afirmación supera la carga máxima, sustituyendo los grupos por una referencia a un endpoint de graph. Si depende de los claims de grupos para el mapeo de roles posterior, configure Azure AD para que emita solo los grupos asignados a la aplicación en lugar de todos los grupos a los que pertenece el usuario.
Cómo verificar que SSO funciona de extremo a extremo
La verificación de extremo a extremo tiene tres fases. Primero, abra una ventana de incógnito y comience el inicio de sesión desde la página de login de SecureCodingHub utilizando una dirección de correo corporativa. El navegador debería redirigir a login.microsoftonline.com, presentar la experiencia de inicio de sesión de Microsoft y, después, redirigir de vuelta a SecureCodingHub. Si la redirección de vuelta falla, capture la barra de URL en el momento del fallo. El código de error en la cadena de consulta es la pieza de evidencia más útil.
Segundo, confirme que el usuario aterriza en la organización y el panel correctos. Un inicio de sesión exitoso con una página principal vacía o una redirección a la organización equivocada suele apuntar a un mapeo de dominio-organización ausente. Tercero, cierre sesión, vuelva a iniciar sesión y verifique que el segundo inicio de sesión es silencioso o casi silencioso. La cookie de sesión de Microsoft debería hacer que el segundo flujo sea casi invisible. Si ambos inicios de sesión requieren una reautenticación completa, su aplicación del IdP está utilizando una política de sesión que impide la reutilización de la cookie de inicio de sesión único. Para pasos compartidos de resolución de problemas, consulte la Guía de configuración de SAML.