Set up mTLS
Register your client certificate, authenticate with mutual TLS, and bind your access tokens so a stolen token is worthless.
Set up mTLS
Protección uses mutual TLS (mTLS) for two things: authenticating your client to the token endpoint, and binding the access tokens it issues to your certificate. A certificate-bound token can only be used by the client holding the matching private key — so even if a token leaks, it can't be replayed.
Security note
Keep your private key in a secrets manager or HSM. Anyone with the key can impersonate your client. Rotate certificates before expiry and revoke immediately if a key is compromised.
Why mutual TLS
In ordinary TLS the client verifies the server. In mutual TLS both sides present certificates: Protección verifies that requests genuinely come from your registered client. mTLS is required for Consumer Data Right–style ecosystems and is the default sender-constraining mechanism on Protección.
Obtain and register a client certificate
Generate a key pair and CSR
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
-keyout client.key -out client.csr \
-subj "/CN=your-client-id/O=Your Company"Submit the certificate for registration
Provide the certificate (or CSR, depending on your onboarding) to Protección through the developer console during recipient onboarding. Protección records the certificate against your client_id and adds it to the trust store for your instance.
Confirm the handshake
curl --cert client.crt --key client.key \
https://secure.proteccion.staging.provider.fiskil.com/connect/parAny HTTP status (even 400) means the mTLS handshake succeeded. A TLS-level error means the certificate isn't trusted yet.
Client authentication methods
Protección accepts these token-endpoint authentication methods (see token_endpoint_auth_methods_supported in discovery):
| Method | How it works | When to use |
|---|---|---|
private_key_jwt | You sign a short-lived JWT assertion with your registered signing key and send it as client_assertion. | Recommended default. Decouples client auth from the transport certificate. |
tls_client_auth | Your CA-issued client certificate itself authenticates the client. | When your ecosystem mandates certificate-based client auth. |
self_signed_tls_client_auth | A self-signed client certificate registered directly with Protección. | Environments without a shared CA. |
private_key_jwt (client authentication) and mTLS (transport + token binding) are complementary. A typical setup authenticates with private_key_jwt and presents a client certificate that the issued token is bound to.
Sender-constrained access tokens
When you authenticate over mTLS, Protección records the SHA-256 thumbprint of your client certificate in the cnf (confirmation) claim of the access token. On every subsequent call it checks that the presenting certificate matches the thumbprint in the token — if not, the request is rejected even when the token is otherwise valid.
{
"iss": "https://public.proteccion.prod.provider.fiskil.com",
"sub": "your-client-id",
"scope": "bank:accounts.basic:read bank:transactions:read",
"exp": 1730000000,
"cnf": {
"x5t#S256": "hL2FQIO7Yb...certificate-thumbprint"
}
}The practical rule: use the same client certificate on your data calls that you used at the token endpoint.
DPoP: an alternative for environments without certificates
For confidential clients that cannot use mTLS, Protección supports DPoP (Demonstration of Proof-of-Possession). You generate an ephemeral key pair and send a signed proof JWT in the DPoP header of each request; the token carries a jkt (JWK thumbprint) confirmation claim instead of x5t#S256.
POST /connect/token HTTP/2
Host: secure.proteccion.prod.provider.fiskil.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0Iiw...
grant_type=authorization_code
&code=auth_code_here
&code_verifier=pkce_verifier
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJ...mTLS is required for CDR-regulated data sharing. Use DPoP only where client-certificate infrastructure is impractical and your ecosystem permits it — confirm with Protección during onboarding.