Providing Credentials

After choosing a connection and using a service, you need to collect credentials for the connection.

The ConnectionInfo contains several metadata that indicates what’s required:

  • The credentials model that specifies what’s supported and required.

  • A label for the user identifier (if supported)

  • An optional advice to display to the user.

Credentials models

The credentials model indicates support for at least one of the following:

  • Full: User identifier and password can be sent for authentication.

  • User ID: Only a user identifier can be sent for typically a decoupled authentication that will get confirmed e.g. in a mobile app.

  • None: No credentials are required. Typically a redirect to the bank’s website will be returned where the user authenticates directly with the bank.

If both User ID and None are provided, passing a user identifier might trigger a decoupled authentication and fall back to a redirect if it is not available. Make sure to pass a user identifier in mobile contexts where a TAN app might be set up on the same device, as the redirect could be dysfunctional in that case (e.g. displaying a matrix code for the app that cannot get scanned).

Connections for which redirect scraping is available to you provide both Full and None for either scraping or using the redirect. Keep in mind that scraping falls back to returning the redirect in case of unexpected errors.

Login form

The login form consists of the following elements:

  • The optional advice from the ConnectionInfo (or your own for the connection), if any.

  • An input for the user identifier, using the label from the ConnectionInfo, if Full or User ID is chosen from the credentials model.

  • An input for the password, if Full is chosen from the credentials model. We recommend a generic label like PIN / Password.

Storage

You can safely store credentials client-side to re-use them with our services at a later stage.

Make sure to never send credentials to your backend services or anything, as you’re entering regulated space if you do.

If you need synchronization between multiple frontends you can use any end-to-end encrypted channel or our services' tokenization facilities.

Tokenization is not yet available.

With tokenization, our service wraps the user’s credentials into an encrypted token that only the service itself can understand. It also adds the user’s consent on what the credentials may be used for. The issued token can be safely distributed, including to your backend services, so it is not only possible to use it for "offline" access, but also to distribute it to other frontends.

Tokens can also get issue for redirects. However, opposed to credentials those come with a bank-specific lifetime.