access-token-authorization

Catálogo de Produtos / access-token-authorization
Interceptors · Paso 2 de 4

access-token-authorization

Valida el access token en el borde: que lo haya emitido un Authorization Server reconocido, que la firma y la vigencia estén bien, que traiga consentimiento, y que esté vinculado al certificado que el llamador presentó.

OrdenSegundo
Punto de ejecuciónRequest
Depende decertificate-client-metadata

01 Qué comprueba, en orden

  1. Emisor dentro de la lista permitida
    El iss del token se compara contra una lista configurada. Las direcciones del Authorization Server nunca se derivan del token.
  2. Firma PS256
    Verificada localmente contra el JWKS del Authorization Server. El algoritmo debe ser PS256.
  3. Vigencia
    exp con una tolerancia de reloj de 30 segundos.
  4. Consentimiento presente
    authorization_details — RAR, RFC 9396 — debe venir en el token. Si se configura un type esperado para el recurso, también se comprueba.
  5. Vínculo con el certificado
    El cnf.x5t#S256 del token debe coincidir con el thumbprint que dejó el paso 1. Es lo que impide usar un token robado desde otro certificado.
  6. Estado del token
    Validación remota contra el Authorization Server, que confirma que el token sigue activo — no revocado, no expirado.
  7. Propagación del consentimiento
    Si el token trae grant_id, se propaga a su servicio en la cabecera grantId.
Por qué el vínculo importa

En el SFA el access token es sender-constrained: vale sólo en manos de quien presenta el certificado para el que fue emitido. El paso 5 es lo que hace efectiva esa garantía en el borde.

02 Configuración

Variables de ambiente

VariableObligatoriaDescripción
environmentNameSíAmbiente de ejecución — por ejemplo sandbox.
customerIdSíIdentificador del customer en la plataforma.
allowed-issuersSíLista (CSV) de emisores aceptados en el iss del token.
jwks-uriSíURL completa del JWKS del Authorization Server.
resource-server-org-idSíIdentificador de organización de su propio resource server. El token sólo se acepta si su aud lo incluye.
auth-server-call-timeoutNoTimeout en milisegundos de las llamadas al Authorization Server. Por defecto 1000.
Cuidado con el nombre

La variable que lleva el ambiente se llama environmentName, no environmentId. environmentId es el nombre de la cabecera con que ese valor viaja hacia el Authorization Server — configurarlo por el nombre de la cabecera no funciona.

Variables de contexto

VariableObligatoriaDescripción
expected-authorization-details-typeNoLista de type RAR esperados para el recurso. Si se omite, sólo se comprueba la presencia de authorization_details.
token-scopeNoScope disponible para el servicio. En el SFA el scope no es el mecanismo de consentimiento — eso lo resuelve RAR.

03 Recomendación de operación

Caché del JWKS

El JWKS se consulta en cada solicitud. Para ambientes con volumen, configure una capa de caché de JWKS en el gateway: reduce la latencia por llamada y la dependencia del Authorization Server en el camino crítico.

04 Errores

codeCuándo
SFA_ERR_UNAUTHORIZEDToken ausente, mal formado, con emisor no permitido, firma inválida, vencido, o no vinculado al certificado presentado
SFA_ERR_INTERNALFallo no previsto durante la validación

05 Código fuente

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

Descargar

access-token-authorization.js — JavaScript, 27 KB.

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

← Anterior: certificate-client-metadata · Siguiente: of-context-params →