Proveedores de identidad: qué son Azure AD (Entra ID), OAuth y OpenID Connect y por qué usarlos

Todo sistema empieza con la misma pantalla: correo y contraseña. Y casi todo sistema termina implementando lo mismo desde cero: registro, hash de contraseñas, recuperación por correo, bloqueo por intentos fallidos, autenticación en dos pasos, sesión, cierre de sesión. Es código que no diferencia a tu producto y que, si tiene una falla, abre la puerta a todo lo demás. En este artículo explicamos qué es un proveedor de identidad, dónde encajan nombres como Azure AD (hoy Microsoft Entra ID), OAuth 2.0, OpenID Connect y SAML, y por qué delegar el inicio de sesión suele ser la decisión más segura y más económica.

Qué es un proveedor de identidad

Un proveedor de identidad (en inglés, Identity Provider o IdP) es el servicio responsable de responder una pregunta: ¿quién es esta persona? Guarda las cuentas, verifica la contraseña o la passkey, exige el segundo factor, aplica las reglas de acceso y, al final, le entrega a tu aplicación un documento firmado que dice “este es el usuario X, autenticado ahora, con estos datos”.

Ya usas proveedores de identidad todos los días: el botón “Iniciar sesión con Google”, el acceso con la cuenta Microsoft del trabajo para abrir Teams, entrar al sistema de la empresa sin escribir otra contraseña. En todos esos casos, la aplicación no ve tu contraseña. Solo recibe la confirmación de quién eres.

En términos técnicos, la aplicación que confía en el proveedor se llama Relying Party (en OpenID Connect) o Service Provider (en SAML). Lo importante es la división de roles: el proveedor se encarga de la identidad y la aplicación, del negocio.

Azure AD, OAuth, OIDC, SAML: qué es cada cosa

Buena parte de la confusión viene de mezclar productos con protocolos. Azure AD es un producto. OAuth es un protocolo. No son alternativas entre sí: Azure AD habla OAuth.

Los productos (los proveedores)

• Microsoft Entra ID (antes Azure AD): el directorio de identidades de Microsoft, incluido en todo tenant de Microsoft 365. Microsoft le cambió el nombre en 2023, pero el servicio, las API y las direcciones de inicio de sesión siguen siendo las mismas. Es la opción natural para sistemas internos de empresas que ya usan Microsoft 365.
• Microsoft Entra External ID: la versión para clientes y socios (el llamado CIAM), sucesora de Azure AD B2C, que dejó de venderse a nuevos clientes en 2025.
• Google: inicio de sesión con cuentas de Google y Google Workspace, muy usado en apps para el consumidor final.
• Okta y Auth0 (de Okta): plataformas independientes en la nube, fuertes en integraciones listas y en la personalización del flujo de inicio de sesión.
• Amazon Cognito: el proveedor de AWS, común en aplicaciones que ya corren allí.
• Keycloak: proveedor de código abierto que alojas en tu propia infraestructura. Sin costo de licencia, pero con el costo de operarlo, actualizarlo y protegerlo.

Los protocolos (el idioma que hablan)

• OAuth 2.0: protocolo de autorización. Resuelve “¿esta app puede acceder a ese recurso en nombre del usuario?” entregando un access token. Es lo que permite, por ejemplo, que un sistema lea tu calendario de Google sin conocer tu contraseña. Por sí solo, OAuth no dice quién es el usuario.
• OpenID Connect (OIDC): una capa de autenticación sobre OAuth 2.0. Agrega el ID token, un JWT firmado con la identidad del usuario. Cuando un sitio dice “login con OAuth”, casi siempre está usando OIDC.
• SAML 2.0: estándar más antiguo, basado en XML, todavía muy presente en sistemas corporativos y en el SSO entre empresas. Funciona bien en aplicaciones web, pero es incómodo para apps móviles y SPA.

Protocolo	Responde	Entrega	Dónde aparece
OAuth 2.0	¿A qué puede acceder esta app?	Access token	API, integraciones entre sistemas
OpenID Connect	¿Quién es el usuario?	ID token (JWT) + access token	Inicio de sesión en sitios, SPA y apps móviles
SAML 2.0	¿Quién es el usuario?	Aserción XML firmada	SSO corporativo y sistemas heredados

Cómo funciona un inicio de sesión con proveedor de identidad

El flujo recomendado hoy para sitios, SPA y apps es Authorization Code con PKCE. En resumen:

1. El usuario hace clic en “Iniciar sesión”. La aplicación lo redirige al proveedor, indicando quién es ella (client_id), a dónde volver y qué necesita (scope).
2. El proveedor muestra la pantalla de inicio de sesión, verifica contraseña, passkey o segundo factor y aplica las políticas de la empresa (país, dispositivo, horario).
3. Si todo está bien, el proveedor devuelve al usuario a la aplicación con un código de un solo uso.
4. La aplicación cambia ese código, directamente con el proveedor, por los tokens: el ID token (quién es el usuario) y el access token (para llamar a las API).
5. La aplicación valida la firma del ID token, crea la sesión y listo: el usuario entró, y la contraseña nunca pasó por tu servidor.

La primera redirección, en el caso de Entra ID, se parece a esto:

GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
    ?client_id={id-de-la-app}
    &response_type=code
    &redirect_uri=https://app.tuempresa.com/signin-oidc
    &scope=openid profile email
    &state={valor-aleatorio}
    &code_challenge={hash-del-verificador}
    &code_challenge_method=S256

El state protege contra la falsificación de solicitudes, y el par code_challenge/verificador (PKCE) garantiza que solo quien inició el inicio de sesión pueda cambiar el código por los tokens. El ID token que vuelve, una vez decodificado, trae algo así:

{
  "iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
  "aud": "{id-de-la-app}",
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "María Sosa",
  "email": "[email protected]",
  "tid": "{tenant-id}",
  "iat": 1794326400,
  "exp": 1794330000
}

Por qué usar un proveedor de identidad

1. La contraseña deja de ser tu problema

Si tu base de datos no guarda contraseñas, una filtración de la base no filtra contraseñas. El proveedor se encarga del hash, de la protección contra fuerza bruta, de la detección de contraseñas filtradas y de la recuperación de cuentas, cosas en las que los equipos grandes se equivocan y que los pequeños ni llegan a implementar.

2. MFA y passkeys sin escribir una línea

Según Microsoft, la autenticación multifactor bloquea más del 99,9% de los ataques de compromiso de cuentas. Con un proveedor, activar MFA, app autenticadora, passkeys (FIDO2/WebAuthn) o inicio de sesión sin contraseña es configuración, no un proyecto.

3. Un inicio de sesión para todos los sistemas (SSO)

El colaborador entra una vez y accede al ERP, al CRM, al portal interno y a las aplicaciones a medida. Menos contraseñas significa menos contraseñas débiles, menos notas pegadas en el monitor y menos tickets de “olvidé mi contraseña”.

4. Se va el empleado, se va el acceso

En la práctica, este es el argumento más fuerte para las empresas. Cuando cada sistema mantiene su propio registro, alguien siempre se olvida de quitar el acceso de quien se fue. Con Entra ID, desactivar la cuenta corta el acceso a todo lo integrado, al instante.

5. Acceso condicional y auditoría

Los proveedores corporativos permiten reglas como “a finanzas solo se accede desde dispositivos de la empresa” o “el inicio de sesión desde el exterior exige MFA”, además de registrar quién entró, cuándo y desde dónde. Esos registros ayudan a responder a incidentes y a demostrar control de acceso en auditorías y ante las leyes de protección de datos.

6. Menos código que mantener

Registro, recuperación de contraseña, verificación de correo, bloqueo, MFA y sesión pasan a ser responsabilidad de un servicio especializado. Tu equipo escribe lo que diferencia al producto.

En la práctica: proteger una aplicación .NET con Entra ID

En ASP.NET Core, la biblioteca Microsoft.Identity.Web hace casi todo el trabajo. Después de registrar la aplicación en el portal de Entra ID, el inicio de sesión en una aplicación web queda así:

// Program.cs
builder.Services
    .AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddAuthorization(o =>
{
    // sin iniciar sesion, ninguna pagina abre
    o.FallbackPolicy = o.DefaultPolicy;
});

// appsettings.json (el secreto va en Key Vault o en variable de entorno)
"AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "{tenant-id}",
  "ClientId": "{id-de-la-app}",
  "CallbackPath": "/signin-oidc"
}

Para una API, el patrón es recibir el access token en el encabezado Authorization: Bearer y validar emisor, audiencia y firma en cada solicitud:

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

En Node.js y Next.js, bibliotecas como Auth.js y openid-client cumplen el mismo papel, y como todos los proveedores hablan OIDC, cambiar Entra ID por Google, Okta o Keycloak suele ser solo configuración.

Los errores más comunes en la integración

• Usar el access token como prueba de inicio de sesión. El access token es para la API. Lo que dice quién es el usuario es el ID token de OIDC.
• No validar el token. Firma, emisor (iss), audiencia (aud) y vencimiento (exp) deben verificarse en cada solicitud. Las bibliotecas oficiales lo hacen; el código casero suele olvidarlo.
• Aceptar cualquier tenant. Las aplicaciones multi-tenant de Entra ID que usan el endpoint common deben verificar el tid, o cualquier cuenta Microsoft del mundo podrá entrar.
• Flujo implícito. El implicit flow devuelve tokens directo en la URL y está desaconsejado por las buenas prácticas actuales de OAuth (RFC 9700). Usa Authorization Code con PKCE.
• Secretos en el front-end o en la app. Las SPA y las apps móviles no pueden guardar secretos. Son clientes públicos y deben usar PKCE.
• Token en localStorage. Cualquier script inyectado en la página lee el localStorage. Prefiere cookies HttpOnly y Secure en el servidor o el patrón backend for frontend.
• Permisos demasiado amplios. Pide solo los scopes necesarios y usa los roles (app roles) y grupos del proveedor para decidir quién puede qué.

Qué proveedor elegir

Escenario	Elección más común
Sistemas internos de una empresa que usa Microsoft 365	Microsoft Entra ID
Sistemas internos de una empresa que usa Google Workspace	Google o un proveedor federado con él
App o portal para clientes finales	Entra External ID, Auth0, Cognito o Firebase Authentication
Muchos sistemas de terceros y SSO corporativo	Okta o Entra ID
Exigencia de correr todo en infraestructura propia	Keycloak

Algunos cuidados valen para cualquier elección: revisa el modelo de precios (muchos cobran por usuario activo al mes, lo que pesa en apps para consumidores), dónde se almacenan los datos y si el proveedor habla OIDC y SAML. Quedarse en los protocolos estándar es lo que evita quedar atado a un proveedor.

Cuándo no vale la pena

Casi siempre vale la pena. Las excepciones son raras: sistemas sin acceso a internet, exigencias regulatorias muy específicas sobre dónde se procesa la identidad o casos en que el costo por usuario hace inviable el modelo de negocio. Aun así, la respuesta suele ser un proveedor autoalojado como Keycloak, y no volver a guardar contraseñas en la tabla usuarios.

Checklist

• La aplicación no almacena contraseñas, solo el identificador del usuario (sub u oid) que viene del proveedor
• Inicio de sesión con OpenID Connect, flujo Authorization Code con PKCE
• Tokens validados en cada solicitud (firma, iss, aud, exp)
• MFA obligatorio, de preferencia con passkeys o app autenticadora
• Permisos por roles y grupos del proveedor, no por listas en el código
• Secretos y certificados de la app en una bóveda (Key Vault o equivalente), con fecha de renovación
• Bajas de colaboradores hechas en un único lugar
• Registros de inicio de sesión revisados y alertas para accesos sospechosos

Fuentes

• Microsoft Learn: nuevo nombre de Azure AD (Microsoft Entra ID)
• Microsoft Learn: flujo Authorization Code en la plataforma de identidad
• IETF RFC 6749: OAuth 2.0, RFC 7636: PKCE y RFC 9700: buenas prácticas de seguridad de OAuth 2.0
• OpenID Foundation: OpenID Connect Core 1.0
• Microsoft Security Blog: MFA y el 99,9% de los ataques a cuentas

¿Necesitas ayuda?

¿Quieres sacar el inicio de sesión de dentro de tu sistema, integrar las aplicaciones de la empresa con Entra ID o Google o agregar SSO y MFA a un portal de clientes? Habla con nosotros: hacemos la integración con el proveedor adecuado para tu caso, sin interrumpir a quienes ya usan el sistema.