Prompt y contexto
Un servidor de recursos acepta un token de acceso normal para lecturas, pero las transferencias, los cambios de cuenta de cobro y las exportaciones sensibles requieren un nivel de autenticación más sólido. Cuando el cliente carece de ese nivel, debe recibir un desafío accionable en lugar de un 403 ambiguo. Diseña el flujo de step-up entre el servidor de recursos, el servidor de autorización y el cliente utilizando RFC 9470.
RFC 9470 define el error insufficient_user_authentication para un desafío Bearer y utiliza acr_values o un contexto de autenticación relacionado para expresar el nivel requerido. La entrevista evalúa el ciclo completo a través de errores de API, claims de token, reautorización, reintentos idempotentes y límites de degradación.
Qué está evaluando el entrevistador
- Distinguir entre fallo de autorización, autenticación insuficiente del usuario y expiración del token.
- Expresar el contexto de autenticación requerido en
WWW-Authenticatesin exponer detalles internos de riesgo. - Permitir que un cliente se reautorice a partir de un desafío evitando al mismo tiempo bucles y degradaciones.
- Verificar emisor, audiencia, scope,
acr,amry claims de tiempo en el servidor de recursos. - Manejar reintentos, concurrencia, auditoría, reversión y experiencia del usuario para escrituras de alto riesgo.
Preguntas para clarificar
- ¿Qué operaciones requieren un nivel superior, y el requisito es un
acr, unamro una confirmación de transacción? - ¿Los tokens de acceso son JWT validados localmente o se realiza introspección? ¿Puede el servidor de recursos ver el contexto de autenticación?
- ¿El cliente es una aplicación web, móvil o de servidor? ¿Están disponibles PKCE, prompt y max_age?
- ¿Debe un desafío ser de un solo uso y estar vinculado al monto, al beneficiario y a un nonce?
- Si el servicio de autorización no está disponible, ¿qué lecturas pueden continuar y qué escrituras deben fallar de forma cerrada (fail closed)?
Respuesta en 30 segundos
Valida primero el emisor, la audiencia, la firma, la expiración y el scope del token. Si el scope es suficiente pero el contexto de autenticación no lo es, devuelve 401 con un desafío Bearer WWW-Authenticate utilizando insufficient_user_authentication y los acr_values y recurso requeridos. El cliente preserva la intención y el estado, se reautentica, recibe un token vinculado a la misma audiencia, scope y contexto, y reintenta una vez. Asigna a los desafíos un TTL corto, reintentos limitados y vinculación a la transacción; nunca degrades silenciosamente las operaciones de alto riesgo.
Respuesta a profundidad
1. Definir la política de autenticación y recursos
Mapea las operaciones con políticas mínimas de autenticación: un nivel básico para lecturas, autenticación resistente al phishing para cambios de cuenta de cobro y confirmación de transacción para transferencias. Evalúa el endpoint, el método, el tenant, el monto y las señales de riesgo en lugar de equiparar cada escritura a un único nivel fijo.
El servidor de autorización define los valores de acr registrados y los métodos de autenticación aceptables. El servidor de recursos acepta únicamente valores registrados; un cliente no puede autoafirmar un nivel superior. amr es una evidencia y no reemplaza la evaluación de políticas de acr.
2. Diseñar la respuesta del desafío
Cuando un token válido carece del contexto requerido, devuelve 401 y un desafío Bearer con error="insufficient_user_authentication". Puede incluir los acr_values requeridos, un identificador de recurso y una URI de error, pero no debe revelar números de cuenta, puntuaciones de riesgo ni reglas internas.
Maneja el contexto faltante o no verificable como insuficiente. Utiliza errores distintos para tokens expirados, emisor no confiable, audiencia incorrecta y scope faltante; no disfraces cada fallo como step-up.
3. Permitir que el cliente se reautorice
El cliente procesa el desafío y vincula el objetivo original, los acr_values requeridos, el recurso y PKCE a una nueva solicitud de autorización. Los clientes web usan state y los clientes OIDC usan nonce; los clientes móviles no deben tratar un desafío no verificado como una URL de autorización ejecutable.
La reautorización aún requiere autenticación y consentimiento en el servidor de autorización. prompt, max_age o una política de autenticación constituyen una solicitud; el servidor escribe el acr alcanzado en el token con base en la autenticación real. El cliente no puede marcar un token como actualizado localmente.
4. Verificar el nuevo token y la intención original
Verifica la firma, emisor, audiencia, scope, exp, iat, acr y los amr requeridos en el nuevo token. Con introspección, exige una respuesta confiable del servidor de autorización con suficiente contexto. El scope por sí solo es insuficiente porque el permiso y la solidez de la autenticación son dimensiones separadas.
Vincula un nonce de desafío, digest de transacción o ID de solicitud de autorización al estado del servidor para acciones de alto riesgo, de modo que un token de autenticación superior no pueda transferirse a otra transacción. Mantén la audiencia del token exacta para la API de destino.
5. Prevenir bucles, reproducción y degradación
Asigna a cada desafío un TTL corto y un ID único, registrando el digest de la solicitud, el tenant, el recurso, el nivel requerido y el conteo de reintentos. Permite uno o un número bajo y acotado de reintentos; consume un desafío exitoso y finaliza los fallidos o expirados.
Rechaza valores menores de acr_values, la sustitución de recursos o audiencias y el regreso a un token ordinario tras el tiempo de espera del step-up. Utiliza claves de idempotencia para las transferencias de modo que los reintentos de autenticación no puedan duplicar efectos secundarios.
6. Manejar la disponibilidad y los límites de error
Si el servicio de autorización o la introspección no están disponibles, las lecturas de bajo riesgo pueden usar una caché breve; las escrituras, los pagos y los cambios de permisos fallan de forma cerrada por defecto. Los errores de desafío no deben revelar métodos de autenticación ni el estado de la cuenta. Los registros retienen el ID de desafío, el emisor, el resultado y la latencia.
Rastrea la tasa de contexto insuficiente, la finalización de desafíos, bucles, expiraciones, reproducciones, fallos de PKCE, denegaciones por acr y efectos comerciales duplicados. Segmenta las alertas por recurso y tenant para separar los errores de política de los ataques.
7. Desplegar y revertir de forma segura
Habilita el step-up primero en una API y tenant, comparando respuestas 401, finalización, latencia, retroalimentación de soporte y denegaciones de alto riesgo. Los clientes que no entienden los desafíos reciben errores documentados y orientación de SDK; los tokens ordinarios no se aceptan silenciosamente para todos.
La reversión desactiva únicamente las políticas de recursos aún no habilitadas y preserva el estado de los desafíos y la auditoría para transacciones activas. Si se filtra contexto, se duplican efectos secundarios o aparecen bucles, pausa el despliegue, revoca la política y vuelve a verificar la vinculación del token.
Respuesta modelo
Definiría un nivel de autenticación mínimo para cada operación. Tras validar un token, el servidor de recursos devuelve 401 con insufficient_user_authentication y un mínimo de acr_values, recurso y URI de error cuando el scope es suficiente pero acr o amr no lo son. El cliente preserva la intención y utiliza state, nonce y PKCE para reautorizarse; el servidor de autorización emite un token cuyo contexto refleja la autenticación real.
El servidor de recursos verifica nuevamente emisor, audiencia, scope, tiempo, acr y los amr requeridos, vinculando un ID de desafío o digest de transacción al estado del servidor. Los desafíos son de corta duración, de un solo uso y con reintentos limitados; se rechazan niveles inferiores, nuevas audiencias y retrocesos incondicionales. Las escrituras de alto riesgo fallan de forma cerrada durante interrupciones de autenticación, y las transferencias utilizan claves de idempotencia.
Errores comunes
- Devolver un 403 o 401 genérico en lugar de un desafío accionable
insufficient_user_authentication. - Verificar el scope pero no el emisor, la audiencia,
acr,amry las claims de tiempo. - Permitir que el cliente autoafirme un
acrmás alto, o que lo reduzca tras un desafío. - Tratar un desafío como una URL de autorización no verificada y omitir state, nonce o PKCE.
- Reintentar indefinidamente u omitir la vinculación a la transacción, permitiendo la reutilización de tokens entre operaciones.
- Degradar silenciosamente transferencias o cambios de permisos cuando la autenticación no está disponible.
- Registrar en logs cuentas, puntuaciones de riesgo o tokens completos.
Preguntas de seguimiento y respuestas
¿Por qué devolver 401 cuando el scope es suficiente pero acr no lo es?
El scope indica a qué puede acceder el token; acr indica cómo se autenticó el usuario. Un recurso puede requerir ambos, por lo que el cliente necesita un nuevo paso de autorización.
¿Qué pertenece a un desafío?
Solo el nivel de autenticación requerido, el identificador de recurso, la URI de error y el identificador de desafío de corta duración necesarios para la acción del cliente. Mantén los detalles de cuenta, monto, riesgo interno y método en el lado del servidor.
¿Puede el cliente llamar al endpoint de token directamente para actualizarse?
No. Debe seguir el desafío a través de la autenticación y el consentimiento en el servidor de autorización. El servidor, no el cliente, afirma el acr alcanzado en el token.
¿Cómo evitas que un token actualizado se use para otra transferencia?
Vincula la audiencia, el recurso, el ID del desafío o el digest de la transacción al estado de un solo uso en el servidor, y usa una clave de idempotencia para la transferencia.
¿Qué ocurre si la introspección no está disponible temporalmente?
Clasifica según el riesgo del recurso. Evidencia breve en caché puede servir para lecturas ordinarias; los pagos y cambios de permisos fallan de forma cerrada cuando el contexto no se puede confirmar.
¿Cómo das soporte a clientes antiguos que no entienden los desafíos?
Publica un error documentado y migración de SDK, luego habilita por tenant. Las operaciones de alto riesgo mantienen su requisito hasta que se complete la migración.