Autorización
Obtén una decisión ALLOW o DENY basada en los permisos vigentes.
POST /v1/authorization/check evalúa el estado canónico para un cliente y una configuración, inmediatamente antes de la operación de negocio. La operación es fail-closed: cualquier estado ausente, vencido o ambiguo produce DENY.
curl --request POST "$CONSENSA_API_URL/v1/authorization/check" \
--header "Authorization: Bearer $CONSENSA_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"userReference": "customer-4821",
"configKey": "credit-evaluation"
}'{ "decision": "ALLOW", "configKey": "credit-evaluation", "validUntil": 1790294400000 }Autoriza la operación solicitada sólo cuando la respuesta sea explícitamente ALLOW. No caches una autorización más allá de validUntil y no conviertas errores de red o servidor en autorizaciones.
Requiere un Flow no ambiguo
Ésta es la restricción que más sorprende al integrar. La operación resuelve la última versión publicada de configKey y exige que sea inequívoca:
- exactamente un consentimiento en el Flow,
- con exactamente un scope requerido,
- y una única combinación requisito/uso en ese scope.
Cualquier otra forma responde DENY con reason: "ambiguous_config". No es un error de configuración del Portal: es que esta operación responde una sola pregunta y no puede adivinar cuál de varios consentimientos querías evaluar.
Para un Flow multiconsentimiento tienes dos caminos: evaluar cada template con GET /v1/customers/{customerId}/consent-compliance, o publicar un Flow dedicado de un solo consentimiento para la decisión de autorización.
Las dos formas de denegar
Una denegación de negocio se comunica como HTTP 200 con decision: "DENY"; no es un error de transporte. Pero hay dos formas distintas y conviene distinguirlas, porque significan cosas diferentes.
Denegación evaluada. Trae configKey y no trae reason. El Flow se resolvió correctamente y el estado del cliente no habilita la operación: no hay consentimiento vigente, está revocado, expiró o no cubre ese scope.
{ "decision": "DENY", "configKey": "credit-evaluation" }Denegación previa a la evaluación. Trae reason y no trae configKey. Consensa no llegó a evaluar nada.
{ "decision": "DENY", "reason": "config_not_published" }reason | Qué pasó |
|---|---|
customer_not_found | Ningún cliente de tu tenant tiene ese userReference. |
config_not_published | No hay versión publicada de ese configKey. |
ambiguous_config | El Flow no tiene exactamente un consentimiento con un único scope requerido. |
config_material_unavailable | La versión publicada existe pero su material de template no se pudo cargar. |
En ambos casos el resultado operativo es el mismo —no trates los datos—, pero sólo la primera forma es una decisión sobre el titular. Las cuatro reason apuntan a tu configuración o a tus referencias, y conviene alertarlas distinto en tu monitoreo.
Qué no es
authorization/check no es lo mismo que el pre-chequeo de POST /v1/embed/sessions. Que presentation.required sea false significa que no hace falta volver a preguntarle al titular en ese instante; no significa que puedas tratar los datos ahora.
Tampoco es lo mismo que consent-compliance, que evalúa un template lógico y responde si hay requisitos pendientes. Compliance informa; autorización decide.
Para REDEC, el gate equivalente es POST /v1/redec/accesses/authorize, que además registra una decisión durable de un solo uso.