Authorization via JWT
JWT is a way for a bank to authorize an operation via call-back
JWT is sent at step 3 via a call-back URL. 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
DCM is capable to manually confirm requests to Identifiers.
Access rules for employees are controlled by DCM.
The private key belongs to DCM
A
csrf_tokenmust be obtained with login-password flow
Header Authorization must contain an actual csrf_token.
Bank generates a JWT
The private key belongs to Bank
No need to authenticate with login-password
Efforts to implement
a key storage
a function to generate a JWT
access rules for employees
only auto-confirmation is available to Identifiers
JWT accompanies all the API requests in header CX-Authorization.
Header Authorization must be empty.
JWT by Bank
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.
Register JWK by bank
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.
Get list of registered keys for bank JWT
When a JWK is registered, you may check if it exists in our register storage.
Check Bank JWT
This feature allows you to check your JWT in our authentication service with no changes to any objects and processes.
JWT by DCM
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.
Get list of registered keys for DCM JWT
You may verify our JWT in your Bank Auth Service using our public key by its kid.
Last updated