Cómo funcionan los proveedores de identidad

¿Qué es un Identity Provider (IdP)?

Un Identity Provider es un servicio que verifica la identidad de un usuario y se la comunica a una aplicación de forma segura. En este proyecto los IdP son Google y Microsoft: la aplicación nunca ve ni almacena la contraseña del bombero; solo recibe una prueba de identidad firmada digitalmente por el IdP.

Analogía: el IdP funciona como una notaría. La aplicación no verifica por sí misma la identidad de la persona; confía en el documento firmado por la notaría (Google o Microsoft), porque tiene una relación de confianza previamente establecida con ella (el client_id y el client_secret).

OAuth2 y OpenID Connect (OIDC)

• OAuth 2.0 es un protocolo de autorización: permite que una app obtenga acceso limitado a recursos en nombre del usuario.
• OpenID Connect (OIDC) es una capa sobre OAuth2 que añade autenticación: define el ID token, un JWT firmado por el IdP que contiene los datos de identidad del usuario (claims).

Cuando el TDR dice "OAuth2", en la práctica la integración usa OIDC sobre OAuth2, que es lo que Google y Microsoft soportan para login.

Actores del flujo

Actor	Quién es en este proyecto
Resource Owner	El bombero voluntario que inicia sesión con su cuenta personal
Client	La aplicación (frontend + backend)
Authorization Server	Google (accounts.google.com) o Microsoft (login.microsoftonline.com)
Resource Server	El backend del sistema, que valida la identidad y consulta el registro UTI

El flujo: Authorization Code Flow + PKCE

Es el flujo recomendado por la industria y el único que debe usarse en aplicaciones web modernas. PKCE protege el intercambio del authorization code incluso si alguien llegara a interceptarlo.

Puntos clave del diagrama:

1. El navegador habla con el IdP, no con nosotros. La contraseña jamás pasa por nuestros servidores.
2. El authorization code no sirve por sí solo: el backend lo intercambia por tokens usando el code_verifier de PKCE y el client_secret.
3. El backend valida el ID token (firma contra las claves públicas del IdP, iss, aud, exp).
4. La autorización es nuestra: a diferencia de un escenario corporativo, aquí el IdP no limita quién entra. El paso 10 —consultar el registro de la UTI— es el que decide si el correo autenticado puede acceder.

El ID token y sus claims

El ID token es un JWT con tres partes (header.payload.signature). El payload trae los claims:

Claim	Significado	Uso en este proyecto
sub	Identificador único del usuario en el IdP	Identificador estable de la identidad
email	Correo del usuario	Clave de autorización: se compara contra el registro de la UTI
email_verified	Si el IdP verificó el correo	Debe ser true para aceptar el login
iss	Issuer: quién emitió el token	Validar que sea Google o Microsoft
aud	Audience: para qué client ID se emitió	Validar que sea nuestro client_id
exp / iat	Expiración / emisión	Rechazar tokens vencidos

Ya no aplican hd ni tid

Al usar cuentas personales, no existe un dominio institucional (hd de Google Workspace) ni un tenant de la Entidad (tid de Microsoft) que validar. La restricción de acceso se implementa con el registro de correos de la UTI, no con claims del token.

Diferencias entre Google y Microsoft

Aspecto	Google	Microsoft
Consola de configuración	Google Cloud Console	Microsoft Entra admin center
Credencial	OAuth 2.0 Client ID (tipo Web)	App registration (client ID + secret)
Tipo de cuentas aceptadas	Cualquier cuenta Google (consent screen External)	Cuentas personales Microsoft (y de cualquier tenant)
Endpoint de login	accounts.google.com	login.microsoftonline.com/common
Requisito de la Entidad	Ninguno (no se necesita Workspace)	Ninguno (no se necesita Entra ID)

El endpoint /common de Microsoft es el que permite iniciar sesión con cuentas personales (Outlook/Hotmail) además de cuentas de trabajo. Ambos IdP exponen un discovery document (.well-known/openid-configuration) con los endpoints y las claves públicas (JWKS) para validar firmas; las librerías OIDC lo consumen automáticamente.