How to integrate with eID Hub

Overview

1. Request an API token
2. Get test users and try the demo application
3. Implement your API integration
4. Get your production credentials

Request an API token

First you will need an API token, please contact us and we can issue you an API token, as there is currently no self-service setup.

The API token will be used for accessing the demo application, and developing your integration (more details below, skip ahead if you want to know the details).

We will initially only provide a token for the testbed environment. Once you have a working integration, production credentials can be requested.

Get test users and try the demo application

We have developed a demo application for the eID Hub that lets you explore the authentication and signing providers available, and what parameters they require and accept. This is accessible only on the testbed environment: https://testbed-eid.scrive.com/demo.html

With the demo application, you select the eID provider you want to use (e.g. Swedish BankID, Norwegian BankID, etc.), along with the method (authentication or signing) and enter any required and optional parameters.

Depending on the eID provider you choose, you may need to install a mobile application, create a test user, or use an existing test user. Details are provided in the test users section of the API documentation

The demo application will send you (via a redirect, pop-up, or an embedded view, depending on the provider) to the eID Hub application, where you then authenticate or sign using the test account. Once that is complete, you will be redirected back to the demo application, where you will see the resulting JSON of the eID Hub transaction (details of the JSON structure in the API documentation).

The demo application serves to experiment with what should be done programmatically via API calls. Meaning that the parameters selected in the demo application should go into an API request’s body.

Implement your API integration

As linked to previously, the API documentation is available here: https://testbed-eid.scrive.com/documentation/api/v1/

The documentation has a section on “Authentication” explaining how to use the API token. There is also a short guide on the “Flow” of using the eID Hub. Finally, also see the video at the end of this guide showing how to expand the definitions in the API documentation, and how they parameters change for auth and sign transactions.

When writing your integration, consider the following points:

1. Use of the eID Hub frontend

   Norwegian BankID, Danish NemID, Finnish FTN, German Verimi, Dutch iDIN and Belgian Itsme all have their own UI. If only integrating to these providers, it’s not necessary to use the eID Hub frontend. For these providers, the eID Hub frontend redirects to or embeds the provider’s own UI.

   For Swedish BankID, SMS OTP, Onfido and Freja, which do not provide a UI, you can either use the eID Hub frontend or implement your own UI.

   If using the eID Hub frontend, you only need to use two API endpoints: one for creating a new transaction and one for retrieving the transaction’s details. If not using the eID Hub frontend, you will need to use one additional endpoint to start transactions.

2. Redirect, pop-up window or embed

   If using the eID Hub frontend, you will need to decide how to use it.

   We strongly suggest using a redirect, as it provides a smooth end-user experience and has the widest compatibility.

   NemID and SMS OTP are the only providers that can be embedded in an iframe. All others should be redirected to or opened in a pop-up window.

   After authentication or signing, the end user is redirected to the URL specified when creating the transaction. The UI behaviour on this URL is defined by the selected strategy:

   • Redirection: next-step page
   • Pop-up window: self-closing script (probably)
   • Embedded: a script that breaks out of the iframe

3. Define provider parameters

   The API documentation describes the necessary parameters for each provider and contains the JSON body fields for each endpoint.

   You can collapse and expand the branches with provider parameters, for example, in the “Add new transaction” section, you can select between auth and sign from a drop-down menu and then expand providerParameters, and then further expand the noBankID branch and see all parameters needed to create a new sign transaction with Norwegian BankID.

   You will also see which parameters are mandatory (marked as Required) and which are optional.

   The response JSON body has a similar nested presentation structure. You can also expand the branches in the documentation. The fields marked as required are always present and will never be null. Other fields may be absent or may be null.

   Be sure to read the section on “Versioning” in the documentation as the addition of new JSON fields is considered a non-breaking change.

Get your production credentials

Once you have a working integration you can request production API tokens. Depending on the eID providers you want to use, we may need to apply for customised credentials on your behalf.