PAFA — Autorización (0.1.0)

RFC 8414 / OpenID Connect Discovery. El perfil exige los valores que el schema fija: una implementación que publique otros no es conforme. Es el lugar donde «sólo FAPI 2.0» se vuelve verificable con un GET.

RFC 9126. Obligatorio: todo pedido de autorización empieza acá, autenticado como cliente (tls_client_auth o private_key_jwt), y el navegador después sólo lleva el request_uri. Acá viaja el alcance, en authorization_details con un elemento de tipo pafa:consent que nombra el consentimiento creado en la parte 1. El authorization server valida en este momento que el consentimiento existe, que es del cliente que pide y que está en AWAITING_AUTHORISATION; si no, responde 400 con invalid_authorization_details.

No se aceptan request objects (request): FAPI 2.0 no los necesita y el perfil no los admite. Un pedido con response_type distinto de code, sin code_challenge, o con code_challenge_method distinto de S256, se rechaza.

El navegador de la persona llega acá con el request_uri de PAR y nada más. La entidad transmisora la autentica con autenticación fuerte —cada vez, antes de emitir el código, y dejando traza; el perfil no dicta los factores (el escrito, decisión 7)—, le muestra el consentimiento en su propia pantalla, con su marca (decisión 8), y la persona elige las cuentas y autoriza o rechaza. El resultado se refleja en el recurso consentimiento (AUTHORISED o REJECTED) y, si autorizó, el navegador vuelve al redirect_uri registrado con code, state e iss (RFC 9207). Nunca vuelve con un id_token ni con una respuesta firmada: el canal frontal no transporta estado.

RFC 6749 con las restricciones del perfil. El cliente se autentica con tls_client_auth (certificado presentado en el handshake, sobre el alias mTLS) o con private_key_jwt (client_assertion), y en los dos casos con una clave o certificado que el directorio atribuye a esa entidad (el escrito, decisión 4).

Atadura del token (decisión 3): si el pedido llega por el alias mTLS, el access token queda atado al certificado (cnf.x5t#S256); si llega con un header DPoP, queda atado a la clave del proof (cnf.jkt) y token_type es DPoP. Un cliente usa siempre la misma atadura; el transmisor acepta las dos. Un pedido sin ninguna de las dos se rechaza con invalid_client.

authorization_code: con code_verifier (PKCE). La respuesta incluye el authorization_details concedido, con el consentimiento ya en AUTHORISED.

refresh_token: no exige offline_access. Antes de emitir, el authorization server verifica que el consentimiento siga AUTHORISED; si no, destruye lo emitido y responde invalid_grant (decisión 6).

client_credentials: para crear y gestionar consentimientos (scope consents), sin authorization_details.

RFC 7662. La llama el servidor de recursos de la misma entidad, autenticado como cliente interno del authorization server, en cada pedido de datos: los access tokens son opacos y ésta es la única forma de saber si siguen vigentes y a qué consentimiento responden (el escrito, decisión 6). La respuesta trae el authorization_details, la atadura (cnf) que el servidor de recursos tiene que verificar contra el certificado o el proof que acompañan al pedido, y la traza de la autenticación de la persona.

Cuando el consentimiento pasó a REVOKED o EXPIRED, el servidor de recursos rechaza aunque active todavía diga true: el dato se protege por el estado del consentimiento, y la limpieza del token es eventual. Por eso la respuesta lleva consent_status además de active.

RFC 7009. El cliente autenticado revoca un access o refresh token propio. No sustituye a la revocación del consentimiento (DELETE /consents/{consentId} de la parte 1): revocar el consentimiento revoca los tokens; revocar un token no toca el consentimiento.