Authorization via JWT
JWT is a way for a bank to authorize an operation via call-back
Last updated
JWT is a way for a bank to authorize an operation via call-back
Last updated
JWT is sent at step 3 via a . In case a response fails, the operation is declined.
The system supports 2 ways of JWT creation. Both approaches can be used simultaneously.
DCM generates a JWT.
Bank validates it against a DCM public key
No efforts to implement:
a key storage
a function to generate a JWT
Access rules for employees are controlled by DCM.
The private key belongs to DCM
A csrf_token must be obtained with login-password flow
Header Authorization must contain an actual csrf_token.
At step 2 Bank generates JWT, that is used at step 5 in header CX-Authorization when Bank Employee makes an operation (e.g. creates a new customer). At step 6 DCM validates the JWT. The same does the bank at step 8.
Steps 3-4 are optional and can be used to check if the JWT is valid.
To jump-start the flow when JWT by bank is used, please register at least one JWK key in our authentication service for your counterparty.
When a JWK is registered, you may check if it exists in our register storage.
This feature allows you to check your JWT in our authentication service with no changes to any objects and processes.
Default scheme (when the JWT is created by DCM) allows you to use the role-based access to the features of the processing system.
DCM generates JWT token at step 4. The bank validates it at step 6.
DCM is capable to manually confirm requests to .
only auto-confirmation is available to
You may verify our JWT in your using our public key by its kid.
