Entrevista de backend: ¿Cómo diseñarías una JWT-Secured Authorization Request en OAuth 2.0?

Consigna y contexto

Eres responsable de un servidor de autorización OAuth 2.0. Las solicitudes de autorización de los clientes contienen scopes de alto valor, resource indicators y contexto de transacción. El equipo quiere que el servidor verifique el origen y la integridad de la solicitud y, en ocasiones, oculte esos parámetros. Diseña una JWT-Secured Authorization Request (JAR): formato del Request Object, firma y cifrado, transporte, tiempo de vida, rotación de claves y manejo de fallas.

Esta pregunta es adecuada para roles de identidad, pagos y backend. La RFC 9101 coloca los parámetros de autorización en un JWT; JWS proporciona integridad y autenticación de la fuente, mientras que JWE puede brindar confidencialidad. Distingue JAR de PAR: JAR protege el request object, mientras que PAR lo envía directamente mediante push al servidor de autorización y devuelve una referencia.

Qué evalúa el entrevistador

• Separación de responsabilidades entre el authorization endpoint, el cliente, el directorio de claves y el token endpoint.
• Validación de issuer, audience, algoritmo, claims de tiempo y parámetros de OAuth.
• Manejo de conflictos con parámetros externos, repetición (replay), abuso de recursos criptográficos o de descompresión y rotación de claves.
• Límites de amenazas claros para JAR, PAR, PKCE, state y nonce.
• Operacionalización mediante observabilidad, despliegue y controles de rollback.

Preguntas clarificadoras

1. ¿El cliente es público o confidencial? ¿El cliente firma el Request Object o lo firma un backend de confianza?
2. ¿Solo necesitamos integridad o los navegadores e intermediarios deben ser incapaces de leer los scopes, recursos y campos de la transacción?
3. ¿Pueden los parámetros externos anular los claims del JWT? ¿Cuáles son las políticas para request y request_uri por cliente?
4. ¿Se trata de un inicio de sesión OIDC, autorización de pagos u OAuth ordinario? ¿Se requieren nonce, autenticación reforzada (step-up) y auditoría sin repudio?
5. ¿Las claves están registradas estáticamente, se sirven a través de JWKS o se guardan en un HSM? ¿Cuáles son los objetivos de rotación y revocación?

Respuesta en 30 segundos

Primero, establece quién puede emitir el Request Object y qué claves y algoritmos son de confianza. Valida iss, aud, client_id, redirect_uri, response_type, scopes, claims de tiempo y un identificador de repetición. Usa un JWS de lista permitida para integridad y autenticación de la fuente; añade JWE cuando la solicitud deba ser confidencial. Trata los claims protegidos del JWT como autoritativos y rechaza conflictos externos. Limita el tamaño y el tiempo de vida, rastrea jti con un TTL y aplica fail-closed para solicitudes de alto riesgo cuando la verificación no esté disponible. JAR protege el objeto, PAR protege el transporte y el tiempo de vida de la referencia, y PKCE vincula al redentor del código de autorización.

Respuesta en profundidad

1. Establecer el límite de confianza del Request Object

El cliente puede enviar un JWT en request o enviarlo mediante PAR y referenciarlo después con request_uri. El servidor de autorización utiliza el registro del cliente para seleccionar emisores y algoritmos confiables; no debe obtener claves arbitrarias solo porque un encabezado JWT contenga kid o jku.

Claims como iss, aud, client_id, redirect_uri, response_type, scopes y recursos deben coincidir con el registro y el contexto de autorización. Los valores externos no firmados no pueden cambiar silenciosamente los valores firmados; los parámetros críticos en conflicto o duplicados se rechazan.

2. Elegir JWS, JWE y la política de algoritmos

Usa JWS cuando se requiera integridad y autenticación de la fuente. Usa JWE cuando la solicitud contenga campos que los navegadores o intermediarios no deban leer. Aplica una lista permitida de algoritmos, rechaza none y el cambio de algoritmo, y limita el tamaño del encabezado, el anidamiento y los bytes totales.

Las claves del destinatario para JWE provienen del registro confiable del servidor de autorización. Las claves de verificación de JWS provienen del registro del cliente o de un directorio JWKS de confianza. Los fallos de descifrado, firma y claims comparten un único límite de error de negocio para que las respuestas no revelen detalles sobre la existencia de claves o solicitudes.

3. Validar claims y ventanas de tiempo

Valida iss, aud, exp y los claims aplicables de nbf y iat. Mantén exp corto; permite únicamente un desfase de reloj (clock skew) acotado. Usa jti o un identificador único equivalente para auditoría y detección de repetición, y rechaza un segundo uso o exige su regeneración.

El servidor sigue realizando una coincidencia exacta del redirect-URI y comprueba los tipos de respuesta y scopes permitidos para el cliente. Una firma JAR válida no significa que un usuario esté autenticado o haya dado su consentimiento; las decisiones sobre sesión, consentimiento, nivel de aseguramiento y riesgo siguen siendo responsabilidades del authorization endpoint.

4. Resolver parámetros externos y orígenes de solicitud

Analiza el origen de la solicitud antes de aplicar la precedencia de parámetros de la especificación. Si request y parámetros de consulta ordinarios aparecen juntos, un valor externo no firmado no debe anular un claim protegido del JWT. Las discrepancias, duplicados o claims críticos faltantes devuelven invalid_request.

Con PAR, el cliente envía el Request Object directamente al servidor de autorización, el cual devuelve un request_uri de corta duración. Luego, el navegador transporta únicamente la referencia, lo que reduce las fugas en URLs y los límites de longitud. PAR no reemplaza la firma o el cifrado de JAR, y JAR por sí mismo no administra el tiempo de vida de la referencia.

5. Resistir la repetición, la sustitución y el abuso de recursos

Usa el ID de cliente más jti como clave de desduplicación en un almacén con TTL; los flujos de alto riesgo pueden requerir consumo de un solo uso. Limita el tamaño del JWT, el anidamiento, la CPU de descifrado y la frecuencia de actualización de JWKS para restringir el abuso criptográfico y de compresión.

Vincula el Request Object al cliente y a la redirect URI. En combinación con PKCE, state y el nonce de OIDC, esto aborda la interceptación del código de autorización, el CSRF de sesión y la sustitución de respuestas de autenticación. Nunca registres en logs JWTs completos, campos de transacción o client assertions.

6. Diseñar directorios de claves y rotación

Asigna a cada clave de verificación de cliente y a cada clave de cifrado del servidor de autorización una versión, un propósito y un estado. Las cachés de JWKS necesitan TTLs explícitos. Durante la rotación, publica la nueva clave, cambia los emisores, conserva la clave antigua durante el tiempo de vida más largo de solicitud o token y luego revócala.

Si falta un kid, permite una actualización controlada del directorio en lugar de reintentos externos ilimitados. La revocación de claves, la caída del directorio y la discrepancia de algoritmos necesitan métricas y alertas; los clientes de alto riesgo aplican fail-closed cuando la verificación no se puede completar.

7. Añadir observabilidad, despliegue y rollback

Registra un hash del request-object, cliente, algoritmo, resultado de la verificación, jti con hash y latencia, nunca texto cifrado ni tokens completos. Rastrea fallas de firma y descifrado, conflictos de claims, expiraciones, jti duplicados, actualizaciones de JWKS y la finalización de autorizaciones.

Habilita JAR por cliente, compara la tasa de finalización, la latencia y la distribución de errores con el flujo anterior, y pausa el despliegue cuando las señales del directorio de claves o de compatibilidad presenten regresiones. El rollback debe restaurar una política explícitamente aprobada; no debe convertir los parámetros externos no firmados en una alternativa de respaldo (fallback) para scopes de alto riesgo.

Respuesta modelo

Trataría a JAR como la capa de integridad y confidencialidad para una solicitud de autorización. El cliente o backend de confianza crea un Request Object de acuerdo con el registro. El servidor de autorización acepta únicamente algoritmos de lista permitida y claves confiables, valida issuer, audience, cliente, redirect URI, response type, scopes, iat/exp y jti, y rechaza valores externos no firmados que entren en conflicto con claims protegidos. Se utiliza JWS para integridad y autenticación de la fuente y JWE para confidencialidad.

Asigna al objeto un tiempo de vida corto y vinculación con el cliente, desduplica jti con un TTL y limita el tamaño, el anidamiento y los recursos de descifrado. Utiliza claves JWKS versionadas con un periodo de superposición durante la rotación. JAR puede combinarse con PAR: JAR protege el objeto, PAR oculta los parámetros del navegador y administra una referencia, mientras que PKCE, state y nonce conservan sus vinculaciones independientes de código y sesión.

Despliega por cliente mientras observas fallas de verificación, repetición, actualizaciones de JWKS, tasa de finalización y latencia. Los fallos en el directorio de claves o las solicitudes de alto riesgo inverificables aplican fail-closed. El rollback restaura una política anterior definida y nunca trata los parámetros externos no firmados como una protección equivalente.

Errores comunes

• Decir que “las firmas JWT son seguras” sin verificar issuer, audience, algoritmo, tiempo y redirect URI.
• Permitir que kid o jku desencadenen la obtención arbitraria de claves por red, ampliando la confianza y el riesgo de SSRF.
• Permitir que los valores de query externos anulen scopes firmados o redirect URIs.
• Tratar a JAR, PAR y PKCE como una sola funcionalidad en lugar de protecciones de solicitud, transporte y código.
• Omitir jti, TTLs cortos, límites de tamaño o límites de recursos criptográficos.
• Eliminar las claves antiguas de inmediato durante la rotación, rompiendo solicitudes aún válidas.
• Recurrir incondicionalmente a la autorización ordinaria tras un fallo de verificación.

Preguntas de seguimiento y respuestas

¿En qué se diferencian las firmas de cliente y de servidor de autorización?

La firma del cliente permite al servidor autenticar el origen de la solicitud y detectar alteraciones. La firma del servidor usualmente transporta una atestación del servidor aguas abajo. Sus anclas de confianza, propósitos de clave y responsables de rotación son distintos.

¿Por qué sigue siendo necesario PKCE cuando JAR está firmado?

JAR protege el contenido de la solicitud; PKCE protege a la parte que canjea el código de autorización. Un callback de navegador interceptado aún requiere el verifier.

¿Debe incluirse cada parámetro dentro del JWT?

Coloca en el Request Object los parámetros que requieran integridad, autenticación de la fuente o confidencialidad. Define la precedencia para los parámetros externos permitidos y rechaza conflictos o valores críticos faltantes.

¿Qué pasa si JWKS no está disponible temporalmente?

Utiliza cachés de corta duración y una única actualización controlada. Si no hay una clave de confianza disponible, aplica fail-closed para solicitudes de alto riesgo y genera una alerta. Nunca aceptes una clave desconocida ni omitas la verificación por disponibilidad.

¿Cómo migras clientes que solo admiten solicitudes ordinarias?

Habilita JAR a través de los metadatos del cliente, mide la verificación y la finalización, y luego exige su uso para los clientes migrados. Configura explícitamente el alcance restante, los límites de riesgo y la fecha límite de retiro (sunset date) para el flujo antiguo.

¿Cómo demuestras que no hay JWTs sensibles en los logs?

Aplica redacción de campos en el gateway, el servicio de autorización y el rastreador de errores. Conserva únicamente los hashes del objeto y de jti, el cliente y el resultado; muestrea logs y ejecuta pruebas de regresión que rechacen tokens, texto cifrado y campos de transacción.