This page shows the different MitID authentication flows that Signicat supports.
Since the process in all the flows are quite similar, we only provide a step-by-step list with image sliders for the "normal" authentication. The difference lies in the step for the chosen authenticator. The following screen examples show the advanced graphical profile in desktop version.
# Normal authentication
The normal MitID authentication flow consists of two main steps (we assume the user has already selected a login link from the service provider site):
- The user enters the username in the MitID Login box.
- The user authenticates using authenticators applicable for the requested LoA or AAL.
If you have set up CPR matching, the user is asked to provide their CPR match after step 2. For more details, see CPR matching.
After a successful login, the Approved screen is displayed and the user is redirected to the service provider site as logged in.
This image slider shows an example of a normal authentication with the MitID app authenticator. This example shows the advanced graphical profile in mobile version.
The flow is quite similar when using the other authenticators. The difference lies in the step for the chosen authenticator:
- MitID app: After having entered the username (no password is needed), the user is asked to approve in the MitID app. The user either approves with a 6-digit PIN or with biometrics (fingerprint or face ID.)
- MitID code display and MitID audio code reader: After having entered the username and password, the user is asked to confirm with a one-time password (OTP) received on their token.
- MitID chip: After having entered the username and password, the user is asked to confirm with their chip.
The chosen authenticator combination also decides the LoA/AAL (see Possible authenticator combinations).
In the Reauthentication flow, you can use the
uuid prefilled parameter to inform Signicat and MitID which user you want to authenticate. The effect of this is that the username screen is skipped and the user is taken straight to the authenticator screen:
To do this, you must already have the
uuid of the user, which is their unique identifier within MitID. This attribute is returned for all MitID authentications in the
mitid.uuid claim for OIDC or the
mitid.uuidattribute for SAML2 (see code examples below).
"login_hint" : ["uuid-7ed3cec8-33cb-4852-bc79-ef3293e1dc52"]
<Extensions> <signicat:Prefilled xmlns:signicat="urn:signicat" Parameter="uuid">7ed3cec8-33cb-4852-bc79-ef3293e1dc52</signicat:Prefilled> </Extensions>
# CPR matching (add-on)
Signicat offers a CPR match flow that can be conducted after a MitID authentication. This is useful, since private service providers are not permitted to do a direct CPR lookup for a user in MitID, but they can match a given CPR number.
This is an example of Signicat's user interface for CPR matching, displayed after the MitID authentication flow (e.g. see Normal authentication):
This example is in mobile version and with an advanced graphical profile.
MitID enforces a maximum limit of three attempts to match the CPR number within a given authentication.
Signicat supports three possible sources that can provide the CPR number for matching: CPR from user, cache and prefilled subject (see below).
# CPR from user
The end-user provides their CPR number themselves by entering it as an input in Signicat’s CPR user interface (see screen example above). This can be considered the default source for the CPR number: If no other source was provided or the prefilled/cached CPR number does not give a positive match, the user will be prompted to provide it themselves. If the user enters an incorrect CPR number, they are met with a warning as well as information detailing how many remaining attempts they have.
# CPR from cache
If the end-user has provided their CPR number and checked the “Remember my CPR number” checkbox in the CPR user interface (see screen example above) and gets a positive match, Signicat will store the number for that user for a period of 90 days (by default). The next time the user conducts a CPR match flow (within the expiration time period and on the same service) the cached CPR will be used for matching, meaning the user will not have to provide it again themselves.
# CPR from prefilled subject
In the CPR match flow, you can use the
subject prefilled parameter to inform Signicat of the CPR number that you want to match against the user being authenticated. The effect of this is that when the user has authenticated, the prefilled subject value will be matched using MitID's CPR matching service. If the match is successful, the transaction will complete without further user action. If the match is unsuccessful, the user will be prompted with the Signicat's CPR user interface (see screen example above) to provide their CPR number manually instead.
See below for OIDC and SAML2 code examples with the
subject prefilled parameter.
<Extensions> <signicat:Prefilled xmlns:signicat="urn:signicat" Parameter="subject">2805542112</signicat:Prefilled> </Extensions>
# Step-up (add-on)
The Step-up flow can be used to reauthenticate a user at a higher LoA or AAL than they were already authenticated at. From the user’s perspective, the difference is that for the Step-up authentication, they do not have to fill in their username and only need to use authenticators that satisfy the new requested LoA/AAL (see Possible authenticator combinations).
If you have the Step-up feature and your method is configured to be used as the basis for a further Step-up authentication, the result will include an
auth_token_id claim for OIDC or an
auth-token-id attribute for SAML2 (see code examples below). To trigger a step-up based on this authentication, you must prefill the received value in your request. Additionally, you must ensure that the Step-up authentication targets a higher LOA or AAL than the original authentication. This can be done either by prefilling the LOA/AAL or by using a preconfigured method with a higher preconfigured LOA/AAL.
In the following examples, we assume that we have received an Auth Token ID for an authentication at LoA Substantial and we wish to conduct a Step-up at LoA High.
"login_hint": ["authTokenId-mitid:27fbcb32-07d3-4d4b-8db4-e98179f3dfae", "assuranceLevel-HIGH", "assuranceMethod-LOA"]
<Extensions> <signicat:Prefilled xmlns:signicat="urn:signicat" Parameter="authTokenId">mitid:27fbcb32-07d3-4d4b-8db4-e98179f3dfae</signicat:Prefilled> <signicat:Prefilled xmlns:signicat="urn:signicat" Parameter="assuranceLevel">HIGH</signicat:Prefilled> <signicat:Prefilled xmlns:signicat="urn:signicat" Parameter="assuranceMethod">LOA</signicat:Prefilled> </Extensions>
# PSD2 (add-on)
Signicat supports using the PSD2 mode in MitID. This ensures that MitID can be used in compliance with the PSD2 RTS (opens new window). Enabling PSD2 mode, restricts the information revealed to the user during a failed multi-factor authentication. For example, a user wants to authenticate using their password, followed by an OTP from their MitID code display. If the user enters the incorrect password and PSD2 mode is enabled, they will not be immediately informed that they entered the incorrect password, as they normally would be. Instead, they will proceed to the MitID code display prompt. Only after completing with the final authenticator, they will be informed that one or more of their authenticators failed, but not which one. The user will then be given the option to restart the authentication process:
The PSD2 feature is available through purchase of the PSD2 Compliance add-on.
# Using personal MitID on behalf of a company (add-on)
Signicat offers an add-on to let your users log on or sign on behalf of the companies they hold signatory rights in. First, the user is authenticated with MitID, which is used to validate their CPR number. Once the CPR number is validated, Signicat does a lookup towards the Danish Erhvervsstyrelsen to check which companies and organisations the user has signatory rights in. The user is then presented with a view that lets them select which of these entities they wish to represent.
As a service provider, you can control certain aspects of the flow:
- Whether or not the end-user is allowed to represent themselves.
- By prefilling a CVR number, the user is required to have signatory rights and is only permitted to log in or sign on behalf of that company (see Prefilling a CVR number).
In the example below, a user has authenticated with MitID and their CPR number has been validated. The user can choose to represent themselves (Helle Jensen) or one of the companies they have signature rights in, e.g. Jensen Services (CVR: 23456789).
If the user then selects to represent Jensen Services, the following attributes will be added to the response:
|OIDC claim||SAML2 attribute||Example value|
# Prefilling a CVR number
As a service provider, if you know in advance which company you want the user to represent, you can accomplish this by prefilling the CVR number of that company. The effect of this is that Signicat will verify that the prefilled CVR number matches one of the companies that the user holds signatory rights in and the user will only be allowed to represent that company during their login.
If the prefilled CVR number has no matches, the service provider will receive the following error code (there will be no error displayed in the UI):
If the user cancels, you will get the standard error code for user cancels:
You can prefill the CVR number as follows:
<Extensions> <signicat:Prefilled xmlns:signicat="urn:signicat" Parameter="cvr">23456789</signicat:Prefilled> </Extensions>