Lección 4 de 410 min
Proveedores de identidad: Auth0 y Microsoft Entra ID
Delegar la identidad en un servicio especializado: qué ofrece cada uno y cómo se integra.
Tu equipo tiene que añadir inicio de sesión a la app. Parece una tarde de trabajo: un formulario y una tabla de usuarios. Luego llega la lista real: guardar contraseñas con un hash adecuado, recuperación por correo, bloqueo tras intentos fallidos, verificación en dos pasos, «Entrar con Google», SSO para los clientes empresariales, auditoría… y mantenerlo todo seguro durante años.
Los proveedores de identidad ofrecen todo eso como servicio: tu app redirige al usuario a ellos, que lo autentican, y recibe tokens estándar de OpenID Connect. En esta lección verás cuándo compensa delegar, dos proveedores muy usados, Auth0 y Microsoft Entra ID, y cómo se integra uno en una SPA.
Construir o comprar
Identidad como servicio
Delegar la autenticación en un proveedor especializado en lugar de construirla tú.
Un proveedor de identidad como servicio (IDaaS) aloja las cuentas de usuario, las pantallas de inicio de sesión, la MFA y las conexiones con otros proveedores, y habla los protocolos estándar: OpenID Connect, OAuth 2.0 y SAML. Tu aplicación solo tiene que redirigir al usuario y validar los tokens que recibe.
La decisión de construir o comprar se reduce a dónde quieres poner tu esfuerzo. Construirlo te da control total y ningún coste por usuario, pero te hace responsable de cada detalle de seguridad. Comprarlo te da funciones maduras desde el primer día a cambio de una cuota y de cierta dependencia del proveedor.
Úsalo cuando
En la mayoría de productos: sobre todo si necesitas login social, MFA o SSO empresarial, o si tu equipo no tiene especialistas en seguridad.
Ten en cuenta
Delegar la autenticación no delega la autorización: qué puede hacer cada usuario en tu app lo sigue decidiendo tu código. Y revisa cómo crece el precio con el número de usuarios y qué supondría migrar a otro proveedor.
Construirlo tú Proveedor de identidad
───────────────────────────────── ──────────────────────────
Hash de contraseñas y migraciones Incluido
Recuperación y verificación de correo Incluido
MFA, passkeys, bloqueo por intentos Incluido, configurable
Login social y SSO por SAML/OIDC Conexiones listas para activar
Autorización en tu API Sigue siendo cosa tuyaAuth0 y Microsoft Entra ID
Auth0
Plataforma de identidad para las apps de tus clientes, de cualquier stack. Parte de Okta.
- Empresa:
- Okta
- Enfoque:
- Identidad de clientes
Auth0 forma parte de Okta desde 2021 y está pensado sobre todo para la identidad de los clientes de tu producto. Su pieza central es Universal Login: una página de inicio de sesión alojada por Auth0, con tu marca, a la que redirige tu app. Detrás de ella activas conexiones: tu propia base de usuarios con contraseña, sociales (Google, Apple, GitHub…), sin contraseña por correo o SMS, y empresariales (SAML, OIDC, Microsoft Entra ID o Active Directory).
Con Actions, funciones de Node.js que se ejecutan en momentos concretos (después del login, antes del registro…), personalizas el flujo: añadir roles al token, bloquear un usuario o llamar a tu CRM. La MFA se activa con códigos de una app, notificaciones push, WebAuthn o SMS, y Organizations modela clientes empresariales (B2B), cada uno con sus miembros, su marca y su propio SSO.
Úsalo cuando
Para apps de consumo o SaaS B2B que necesitan login social, SSO con las empresas cliente y personalización del flujo, sin depender del ecosistema de Microsoft.
Ten en cuenta
El coste crece con los usuarios activos y algunas funciones (como ciertas opciones de MFA o de Organizations) dependen del plan. Compruébalo antes de diseñar en torno a ellas.
exports.onExecutePostLogin = async (event, api) => {
// Bloquea a los usuarios marcados en sus metadatos
if (event.user.app_metadata.bloqueado) {
return api.access.deny("Cuenta bloqueada");
}
// Añade los roles del usuario al access token
api.accessToken.setCustomClaim(
"https://ejemplo.com/roles",
event.authorization?.roles ?? [],
);
};Microsoft Entra ID
El servicio de identidad en la nube de Microsoft, antes llamado Azure AD.
- Antes:
- Azure Active Directory
- Librerías:
- MSAL
Microsoft Entra ID, que hasta 2023 se llamaba Azure Active Directory, es el directorio en la nube detrás de Microsoft 365 y Azure. Cada organización tiene su tenant, una instancia aislada con sus usuarios, grupos y aplicaciones, identificada por un id y un dominio como empresa.onmicrosoft.com.
Para que tu app use Entra ID, creas un registro de aplicación (app registration): obtienes un client ID, registras las redirect_uri, declaras el tipo de plataforma (SPA, web, móvil), los permisos que pide (por ejemplo, sobre Microsoft Graph) y, si es una API, los scopes que expone.
Pese al nombre antiguo, no es Active Directory en la nube. AD local vive en la red de la empresa y habla LDAP y Kerberos, con unidades organizativas y directivas de grupo. Entra ID habla OAuth 2.0, OpenID Connect y SAML por internet. Muchas empresas tienen los dos y sincronizan las cuentas de AD hacia Entra ID.
Úsalo cuando
Para apps que usan los empleados de organizaciones que ya trabajan con Microsoft 365, y para llamar a APIs de Microsoft como Graph (correo, calendario, Teams).
Ten en cuenta
Decide al registrar la app si aceptas cuentas de un solo tenant o de cualquier organización: cambia el emisor de los tokens y cómo debes validarlo. Para apps dirigidas a consumidores, Microsoft ofrece un producto aparte, Entra External ID.
Acceso condicional
Reglas de Entra ID que deciden cómo se entra según quién, desde dónde y con qué.
El acceso condicional (Conditional Access) son directivas del tipo «si… entonces…». Las condiciones miran el usuario o grupo, la aplicación, la ubicación, el tipo de dispositivo o el riesgo del inicio de sesión; las acciones pueden exigir MFA, exigir un dispositivo administrado por la empresa o bloquear el acceso.
Así, la misma app puede pedir solo la contraseña desde la oficina y MFA desde fuera, o bloquear el acceso desde países donde la empresa no opera. Tu aplicación no tiene que programar nada: lo aplica Entra ID antes de emitir los tokens.
Úsalo cuando
Cuando la seguridad del acceso depende del contexto y quieres gestionarla de forma central para todas las aplicaciones del tenant.
Ten en cuenta
Requiere una licencia de pago de Entra ID. Y prueba cada directiva en modo informe antes de activarla: una regla mal hecha puede dejar fuera a toda la empresa, incluidos los administradores.
Si: usuario ∈ grupo «Finanzas»
y aplicación = «Portal de pagos»
y ubicación ∉ «Oficinas»
Entonces: exigir MFA y dispositivo administradoMSAL
Las librerías oficiales de Microsoft para obtener tokens de Entra ID.
MSAL (Microsoft Authentication Library) es la familia de librerías que implementa los flujos de OAuth y OpenID Connect contra Entra ID: @azure/msal-browser para JavaScript en el navegador, MSAL React, MSAL Angular, MSAL Node, MSAL.NET, Python, Java, iOS y Android. Sustituye a la antigua ADAL.
En una SPA usa Authorization Code con PKCE, guarda los tokens en su caché y los renueva sola. El patrón es pedir el token en silencio con acquireTokenSilent y, solo si hace falta interacción, redirigir al usuario. MSAL Angular añade un guard para proteger rutas y un interceptor que adjunta el token correcto a las peticiones según la URL.
Úsalo cuando
Siempre que tu app obtenga tokens de Entra ID, ya sea para tu propia API o para Microsoft Graph.
Ten en cuenta
Pide los tokens por recurso: un token para Graph no vale para tu API, porque su aud es distinto. En MSAL Angular, eso se configura en el protectedResourceMap del interceptor.
import { PublicClientApplication } from "@azure/msal-browser";
const msal = new PublicClientApplication({
auth: {
clientId: "id-de-tu-app-registration",
authority: "https://login.microsoftonline.com/id-de-tu-tenant",
redirectUri: "https://app.ejemplo.com",
},
});
await msal.initialize();
await msal.handleRedirectPromise(); // procesa la vuelta del login
const cuenta = msal.getAllAccounts()[0];
if (!cuenta) {
await msal.loginRedirect({ scopes: ["User.Read"] }); // sale hacia Entra ID
} else {
const { accessToken } = await msal.acquireTokenSilent({ scopes: ["User.Read"], account: cuenta });
// Úsalo en la cabecera Authorization: Bearer …
}Integrar un proveedor en una SPA
Redirección, callback y tokens
El recorrido completo, el mismo con cualquier proveedor: lo cambia solo el SDK.
La integración sigue siempre los mismos pasos. Al pulsar «Entrar», el SDK redirige al proveedor con un desafío PKCE. El usuario inicia sesión allí y vuelve a tu ruta de callback con un código, que el SDK canjea por un ID token (para mostrar quién es) y un access token (para tu API). Después, el SDK adjunta el access token a las llamadas a tu API y lo renueva antes de que caduque.
Los SDK oficiales, como auth0-angular o MSAL Angular, resuelven todo eso con unas pocas líneas de configuración: un proveedor, un interceptor HTTP y un guard para las rutas privadas. Tu API, por su parte, valida cada access token: firma con el JWKS del proveedor, emisor, audiencia y caducidad.
Úsalo cuando
Al conectar cualquier SPA con un proveedor de identidad. Empieza siempre por el SDK oficial y su guía rápida para tu framework.
Ten en cuenta
Ocultar un botón en el frontend no protege nada: un guard solo mejora la experiencia. La seguridad real está en la API, que debe rechazar cualquier petición sin un token válido y comprobar los permisos.
import { provideAuth0, authHttpInterceptorFn } from "@auth0/auth0-angular";
export const appConfig: ApplicationConfig = {
providers: [
provideAuth0({
domain: "mi-empresa.eu.auth0.com",
clientId: "id-de-tu-aplicacion",
authorizationParams: {
redirect_uri: window.location.origin,
audience: "https://api.ejemplo.com", // para recibir un access token de tu API
},
httpInterceptor: { allowedList: ["https://api.ejemplo.com/*"] },
}),
provideHttpClient(withInterceptors([authHttpInterceptorFn])),
],
};
// En un componente: inject(AuthService).loginWithRedirect()Nota
Si cambias de proveedor, lo que cambia es el SDK y la configuración. Los conceptos (Authorization Code con PKCE, ID token, access token, validación con JWKS) son los mismos que viste en las lecciones de OAuth y JWT.
Interactivo
Auth0 frente a Microsoft Entra ID
Activa o desactiva opciones para compararlas cara a cara.
| Característica | Auth0 | Microsoft Entra ID |
|---|---|---|
| Pensado para | La identidad de los clientes de tu producto, en cualquier stack | La identidad de los empleados de una organización con Microsoft 365 |
| Usuarios típicos | Consumidores y empleados de tus clientes B2B | Empleados e invitados; consumidores, con Entra External ID |
| Conexiones con otros proveedores | Sociales, base de datos propia y empresariales (SAML, OIDC, Entra ID, AD) | Federación con otros IdP y sincronización con AD local |
| Personalizar el flujo | Universal Login con tu marca y Actions en Node.js | Acceso condicional, grupos y roles de aplicación |
| Librerías | SDK propios: auth0-angular, auth0-react, auth0-spa-js… | MSAL: msal-browser, MSAL Angular, MSAL.NET… |
Ponlo en práctica
Saber qué es cada cosa es la mitad del trabajo. La otra mitad es reconocer cuándo usarla.
Interactivo
¿Qué usarías?
Lee cada situación y elige la opción que mejor la resuelve. Fallar aquí no cuenta: es para practicar.
Una startup lanza una app de recetas para el público general. Quiere «Entrar con Google» y «Entrar con Apple», y su equipo es de tres personas.
Para recordar
- Un proveedor de identidad te da login, MFA, login social y SSO con protocolos estándar; la autorización sigue siendo cosa tuya.
- Auth0 se centra en la identidad de los clientes: Universal Login, conexiones, Actions y Organizations.
- Microsoft Entra ID, antes Azure AD, es la identidad en la nube de las organizaciones con Microsoft 365; no es Active Directory en la nube.
- MSAL es la forma oficial de obtener tokens de Entra ID; MSAL Angular añade guard e interceptor.
- Integrar un proveedor en una SPA siempre es redirección, callback y tokens, y la API valida cada access token.
Comprueba lo aprendido
Cuestionario
Responde las 5 preguntas para completar la lección.
1.¿Cuál es la diferencia principal entre Active Directory local y Microsoft Entra ID?
2.En MSAL, ¿por qué se llama primero a
acquireTokenSilent?3.¿Para qué sirve una Action post-login en Auth0?
4.Tu SPA usa un guard para que solo los administradores vean la página de usuarios. ¿Está protegida esa información?
5.Al delegar la identidad en un proveedor como Auth0 o Entra ID, ¿qué sigue siendo responsabilidad de tu aplicación?