OpenID Connect · OAuth 2.0
El protocolo nunca ha dejado de evolucionar. Esto es lo que pasó, por qué y lo que ID-Kit ya puede probar.
Primera versión: cada llamada se firma. Compleja de implementar, de ahí lo que siguió.
El protocolo se convierte en un RFC.
El marco actual: code, implicit, password, client credentials, más los tokens Bearer.
Invalidar un token antes de que caduque.
La identidad sobre OAuth: ID token, userinfo, scopes estándar, discovery.
El formato de token firmado y la autenticación por aserción (SAML o JWT) en lugar de un secreto. ID-Kit: JWT y aserción JWT en el lado del proveedor de pruebas (no la aserción SAML).
Un cliente puede registrarse por sí mismo mediante una API.
Vincula el código a quien lo solicitó. Nació para el móvil, hoy se exige en todas partes.
Pregunte al proveedor si un token está activo.
Navegador del sistema en lugar de vista integrada. Fin de las contraseñas escritas en la aplicación.
Discovery de OAuth (el equivalente de .well-known/openid-configuration).
Iniciar sesión desde un dispositivo sin teclado, a través de otra pantalla.
Intercambiar un token por otro (delegación, cambio de audiencia).
Autenticación del cliente por certificado y tokens vinculados al certificado.
La solicitud de autorización es un JWT firmado.
Enviar la solicitud de autorización de servidor a servidor.
Un formato estándar para los access tokens JWT (typ at+jwt).
CIBA: autenticación en otro dispositivo. JARM: respuesta de autorización como JWT firmado.
Protege contra el ataque «mix-up».
Autorizaciones detalladas («pagar 50 € a X») en lugar de scopes simples.
Un token vinculado a una clave del cliente; una API puede exigir una autenticación más fuerte.
Core, Discovery, Dynamic Registration y las especificaciones de cierre de sesión publicadas como ISO/IEC 26131 a 26139.
El «BCP» que entierra implicit y password e impone PKCE y la comparación exacta de redirect_uri.
Una API anuncia qué servidor de autorización acepta.
Perfil de seguridad financiera (PAR, PKCE, tokens vinculados) e identidades verificables: emisión y presentación de credenciales en una cartera digital.
Divulgación selectiva en un JWT; señales de seguridad compartidas entre proveedores (revocación continua).
Cadenas de confianza entre proveedores y clientes, a gran escala (educación, administraciones públicas).
Consolida OAuth 2.0 y las buenas prácticas: se eliminan implicit y password, PKCE obligatorio. Aún no es un RFC a fecha de 31 de octubre de 2026.
Identity chaining (propagar la identidad entre dominios), rfc7523bis (revisión de la autenticación JWT), Status List, revisión de las buenas prácticas JWT.
Decenas de borradores sobre la autorización de agentes: Transaction Tokens, delegación, Identity Assertion Authorization Grant. Nada se ha estabilizado: para seguir, no para implementar.
Fuentes: oauth.net/specs, openid.net/developers/specs. Fechas comprobadas el 1er noviembre de 2026; algunas entradas solo tienen el año. Vea también los flujos en diagramas y ¿Qué flujo debo elegir?