BDDK Integration Overview
BDDK Integration consists of two parts: the backend integration and the integration of the mobile applications.
Integration Parts
The following diagram depicts the event flow of the login process. For more details, see the KSSIDP overview. MCSDK events are described in the events list, and helper classes are documented here.
- KOBIL is responsible for everything that is blue.
- The banks are responsible for everything that is red.
Remarks
Regarding the 1st red box:
Each token contains a key-ID in the header. The process should be:
- When the service starts, call the JWKS endpoint of the KOBIL IDP to fetch keys and cache them in memory. This is essentially a map of key-ID to key. There are libraries to handle JWKS formats, and there may even be libraries that can manage the cache and connect to the KOBIL IDP automatically.
- When verifying a token, resolve the key-ID against the in-memory cache.
- If the key is not in the cache, refresh it (same call as on startup).
- If the key still does not exist, reject the token.
There are usually libraries that provide token verification code already (often with a handler to resolve unknown key-IDs).
Regarding sessions:
If the backend calls are stateless, the bank would have to handle parts of the session in their JavaScript client.