How to integrate with eID Hub - MitID
Overview
For a general overview of the integration process see How to integrate with eID Hub. It describes the steps that have to be done to integrate with any eID. This guide goes more into details specifically for the integration with MitID.
- Authentication / Signing flow
- UI customization
- Level of Assurance in MitID
- Authentication response validation
Authentication / Signing flow
MitID security requirements demand the authentication to be done on a mitid.dk
subdomain, which in our case is scrive.mitid.dk
. Therefore the Service Providers are required to redirect their users to eID Hub frontend to perform the authentication (or signing).
This is how the flow between the end user, you (Scrive’s customer, or Service Provider, SP) and eID Hub’s backend and frontend looks like:
Three actions are required from SP to perform:
-
Call
/transaction/new
endpoint with parameters. MitID-specific parameters are the interface language, LoA level, display text and CPR. All parameters are optional for authentication, some are mandatory for signing. See API documentation for details. -
Redirect the end-user to
accessUrl
returned by the above call. -
Collect and verify the transaction details from
/transaction/{t_id}
after the user is redirected back to you, toredirectUrl
, specified in step 1.
UI customization
eID Hub frontend, accessible at accessUrl
, looks like the following image. The background color, logo and page title are customizable. SP name is set once you become Scrive’s customer and we register you with MitID as an SP.


Please contact our support if you want a customization.
Level of Assurance in MitID
MitID authentication is based on being able to specify the required assurance level before the actual authentication.
In eID Hub one can specify the required LoA level. This leads to end users who don’t have the required level not being able to authenticate (they’ll be shown an explanation that a higher assurance level is required).
IAL (identity assurance level) is initially assigned as part of the registration process with MitID and later only modifiable through additional registration processes.
AAL (authentication assurance level) is calculated on the basis of the authenticators that are used, e.g. only using password would result in a Low AAL, and using 2FA with MitID mobile application would result in Substantial or High.
LoA (level of assurance) is calculated as the minimum of IAL and AAL.
Authentication response validation
When the end user has authenticated, we retrieve the user data from MitID and perform mandatory steps to assure high security level. We validate the MitID response and signature, repack and sign the data ourselves, as required by the MitID Broker protocol. You must verify the signature we put in the response. Signed data is represented by the JWS format. We host the keys for the signature verification on a separate endpoint (see API documentation). You need to fetch these keys and verify the signature.