Autenticación
Usa API keys y scopes desde el backend sin exponer credenciales al navegador.
La Integration API usa una API key ligada a tu tenant, enviada como Authorization: Bearer. Consérvala únicamente en el backend del integrador.
Authorization: Bearer <api-key-de-tu-backend>Nunca envíes API keys, cookies, contraseñas ni tokens de sesión bancaria al Web Component.
Scopes
Los scopes se evalúan por operación. Una API key sin el scope necesario responde 403 con consent_api_scope_required y la lista de scopes faltantes en error.details.
| Scope | Para qué sirve |
|---|---|
consent:read | Leer consentimientos, interacciones, Evidence, lecturas regulatorias REDEC y authorization/check. |
consent:runtime | Crear sesiones de Embed y de Centro de Privacidad, revocar, y todas las escrituras REDEC. |
consent:identity-assert | Afirmar identidad o autenticación ya verificada por tu organización. |
dsr:manage | Leer solicitudes de derechos del titular y confirmar su ejecución. |
consent:config existe para configurar consentimientos y Flows, pero eso se hace desde el Portal: ninguna operación de esta referencia lo usa.
Cuándo hace falta consent:identity-assert
Es un scope condicional. Lo necesitas cuando tu organización afirma algo sobre la identidad del titular, en tres situaciones:
- Crear una Embed Session con
authentication.source: "client", es decir, cuando declaras que ya autenticaste al cliente. Consource: "consensa"el runtime administrado hace la verificación y este scope no es requisito. - Crear una sesión de Centro de Privacidad, que siempre es
source: "client": ahí el scope es obligatorio junto conconsent:runtime. - Enviar
identifiers[].verificational resolver un cliente o al crear una sesión, con la provenance real (method,sourceReference,verifiedAt).
El scope te permite afirmar provenance. No convierte un método concreto en un nivel de assurance universalmente suficiente para todos los canales o Regulatory Profiles: eso lo decide el perfil publicado.
Lo que no controla quien llama
Consensa rechaza cualquier intento de autodeclararse verificado:
verifieden el cuerpo o dentro de un identifier →verified_not_caller_controlled.verifiedoproviderdentro deverification→verification_provenance_not_caller_controlled.internalConsentCodeen un otorgamiento REDEC →internal_consent_code_is_server_generated.
La política de autenticación de un Flow (authentication.policyCode) se congela al publicarlo en el Portal y es la única autoridad sobre source y el perfil de verificación. Tu backend aporta la evidencia que satisface la política; nunca elige ni rebaja la política.