of-consent-validation

Catálogo de Produtos / of-consent-validation
Interceptors · Paso 4 de 4

of-consent-validation

Último paso de la cadena. Comprueba que el consentimiento que viaja en el token cubra exactamente la operación que se está solicitando — no basta con que el token sea válido.

OrdenTercero
Punto de ejecuciónRequest
Depende deaccess-token-authorization

01 El modelo

La verificación es token-based: el consentimiento se lee del propio access token, no se consulta a un servicio externo.

El paso anterior ya verificó la firma del token y confirmó con el Authorization Server que sigue activo. Revocación y expiración, por lo tanto, ya están cubiertas antes de llegar aquí. Lo que queda por decidir es distinto: si lo que el titular autorizó alcanza para lo que se está pidiendo.

02 Qué comprueba

  1. El recurso declara qué exige
    Cada operación se configura con el type que requiere y, opcionalmente, con las actions que necesita.
  2. El token trae ese type
    Debe existir al menos una entrada de authorization_details con el type requerido. Si no, se responde 403.
  3. Las actions alcanzan
    La unión de las actions concedidas para ese type debe cubrir todas las exigidas. Si falta una, se responde 403.
  4. Propagación opcional del contexto
    Si se habilita, el consentimiento resuelto se propaga a su servicio en x-consent-context.
Sobre qué se decide

El enforcement se basa en type y actions, que son los campos que el esquema del SFA garantiza. Otros atributos que puedan venir en authorization_details son extensiones y no se usan para autorizar.

03 Configuración

Toda la configuración es por contexto, es decir, por API y por operación — es lo que permite que dos endpoints del mismo servicio exijan permisos distintos.

Normalmente no se configura a mano

El paso anterior, of-context-params, resuelve context-authorization-type y context-required-actions desde la ruta del recurso y las inyecta. Configúrelas a mano sólo cuando quiera apartarse de ese mapeo: el valor manual tiene prioridad.

VariableObligatoriaDescripción
context-authorization-typeSíEl type RAR que el recurso exige.
context-required-actionsNoLista de actions que deben estar todas concedidas. Si se omite, sólo se valida la presencia del type.
forward-consent-contextNotrue para propagar x-consent-context hacia su servicio. Por defecto no se propaga.
Configuración faltante

Si context-authorization-type no está configurada para el recurso, la solicitud se rechaza. Es deliberado: un recurso regulado sin exigencia declarada quedaría abierto a cualquier consentimiento.

04 La cabecera x-consent-context

Cuando la propagación está habilitada, su servicio recibe el contexto del consentimiento codificado en base64url:

// contenido antes de codificar
{
  "sub":            // titular del consentimiento
  "grantId":        // identificador del consentimiento
  "type":           // el type RAR exigido por el recurso
  "grantedActions": // las actions efectivamente concedidas
}

05 Errores

codeCuándo
SFA_ERR_FORBIDDENEl type exigido no está en el token, o las actions concedidas no cubren las requeridas
SFA_ERR_INVALID_GRANTEl consentimiento del token no es utilizable
SFA_ERR_UNAUTHORIZEDNo hay consentimiento legible en el token
SFA_ERR_INTERNALFallo no previsto, incluida la falta de configuración obligatoria

06 Código fuente

El interceptor completo, tal como se instala en la Sensedia API Platform.

Descargar

of-consent-validation.js — JavaScript, 13 KB.

Se sirve con extensión .json porque el portal no entrega archivos .js; el contenido es JavaScript. Guárdelo como of-consent-validation.js.

← Anterior: of-context-params · Volver a Interceptors