OIDC y OAuth

Endpoints de discovery, autorización, token, cierre de sesión y extensiones OAuth.sesión y extensiones OAuth.

Puntos de conexión principales

Punto de conexión	Descripción
`/.well-known/openid-configuration`	Descubrimiento OIDC para el emisor actual.
`/.well-known/oauth-protected-resource`	Metadatos de recurso protegido OAuth para endpoints de recursos alojados en XID.
`/jwks`	Claves públicas de firma de la instancia con kids activos y en rotación.
`/authorize`	Punto de conexión de autorización con PKCE, state, nonce, PAR y traspaso a Hosted Auth.
`/par`	Pushed Authorization Requests con valores request_uri de un solo uso.
`/token`	Código de autorización, token de actualización, credenciales de cliente, código de dispositivo e intercambio de tokens.
`/userinfo`	Declaraciones de usuario de un token de acceso Bearer o DPoP.
`/end_session`	Cierre de sesión iniciado por RP con redirecciones posteriores al registradas.

PKCE usa S256. Se rechaza PKCE sin transformación.
La coincidencia de URI de redirección es exacta. No se aceptan comodines.
Los códigos de autorización son de un solo uso.
Los tokens de actualización rotan en cada uso y una reproducción revoca la familia de tokens.
Los clientes vinculados con DPoP deben presentar una prueba DPoP valida para llamadas de token y recursos. El dpop_jkt de la solicitud de autorizacion se vincula al intercambio del authorization code.

Nivel	Funciones OAuth y OIDC
Implementado	Código de autorización, PKCE S256, rotación de refresh, PAR, prueba DPoP y enlace `dpop_jkt`, registro dinámico de clientes, ID tokens, userinfo, tipos de respuesta híbridos, objetos de solicitud JAR firmados, respuestas JARM firmadas, detalles de autorización RAR`resource_access`, refresh de token exchange y emisión de ID token, autenticación de cliente mTLS y cierre de sesión front-channel.
Provider-ready	El sondeo de autorización de dispositivo, check_session de Session Management, aprobación CIBA backchannel, puertas de perfil FAPI 2.0 / Browser-Based Apps, OpenID Federation y Shared Signals exponen subconjuntos limitados o provider-ready. GNAP, UMA, HEART, OpenID4VP y OpenID4VCI devuelven stubs negativos o 501 hasta que estén los perfiles completos.
Planificado	OIDC SaaS descendente usa localmente la línea base OIDC genérica actual, pero el soporte de producción específico de SaaS aún requiere SaaS L4 real.
Obsoleto o no compatible	Flujo implícito, password grant, PKCE plain y redirecciones con comodín.

Rol de XID	Estado público actual
Proveedor de identidad OIDC / OAuth para aplicaciones de clientes	Implementado en rutas locales y de Worker con cobertura de código de autorización, PKCE S256, PAR, DPoP, JAR, JARM, RAR, discovery, JWKS, token, userinfo, introspección y revocación.
Relying party OIDC empresarial upstream	Estado provider-ready para conexiones empresariales. La compatibilidad con producción requiere una configuración de IdP real y una L4 de callback.
Relying party de OAuth social	Estado provider-ready para GitHub, Google, cuentas de Microsoft y Apple. Consulta Inicio de sesión social para conocer los límites específicos de cada proveedor.
Proveedor de identidad OIDC para SaaS downstream	La base genérica de OIDC está disponible localmente. Aún se requieren plantillas de aplicaciones específicas de SaaS y una L4 real de SaaS antes de declarar compatibilidad con producción.

Cliente	Flujo recomendado
Aplicación web	Código de autorización con intercambio de tokens del lado del servidor.
SPA	Código de autorización con PKCE S256.
App nativa	Código de autorización con PKCE S256 y redirecciones declaradas.
Máquina a máquina	Credenciales de cliente con acceso limitado.

Nivel	Estado
Grants de asercion	Los assertion grants JWT bearer y SAML bearer no estan habilitados. El registro rechaza metadatos de assertion grant hasta que exista una raiz de confianza.
GNAP, UMA, HEART, OpenID4VP, OpenID4VCI	Se exponen subconjuntos mínimos de rutas y metadatos aptos para discovery. Las operaciones no soportadas devuelven errores explícitos hasta que estén los manejadores de perfil completos.