How to request a specific e-ID
When requesting authentication through Criipto Verify you must specify exactly which kind of e-ID the user will use, often including a choice of one out of more options for each type. For example, Swedish BankID allows to different methods, either on the same device or on another device.
The following descrribes you options for specifying which specific e-ID method you will request.
You can see the list of supported values for e-ID methods here.
Option 1: The standards-based approach
The recommended way of specifying the e-ID method is to send an
acr_values as a query parameter when using OpenID Connect. (If you use WS-Federation, the choice is sent in the
This is a straightforward excercise in most clients technologies when you integrate directly with Criipto Verify.
In some cases, however, you don’t have an option to control how (or if) this parameter is set at runtime. That can be the case when you are working in a less flexible setup, such as
- Connecting your client application to Criipto Verify via an intermediary identity provider
- Connecting SaaS-based solutions with Criipto Verify
In cases where you cannot specify the
acr_values parameter please see below for ways to get around this.
Option 2: Embed e-ID method in the URL-path
You can embed the chosen e-ID method in the URL path that your client application uses to request authentication on as described in detail here. This approach works for both OpenID Connect (OIDC) and WS-Federation, but is typically something you would set up during configuration time, so it is not very flexible.
Basially you encode the e-ID method, the value you would otherwise put in the
acr_values query parameter. As an example consider the retrieval of the OIDC discovery document for Swedish BankID same device with a Base64 encoded
Option 3: Embedded in the login_hint query parameter (OIDC only)
Specifically for OpenID Connect some intermediate services, for example Auth0, will relay a provided
login_hint to upstream identity providers such as Criipto. Exploiting this option you may use this parameter to communicate the choice of e-ID method.
You must use the following format for the embedding:
Note The separator between the
acr_values token and the actual value is a colon (
As an example, when you want same-device Swedish BankID, send the following:
You can also use this workaround in conjunction with sending other prefilled fields in the
Option 4: In an HTTP header (OIDC only)
You can also send the targeted e-ID method in an
acr_values HTTP request header:
acr_values: <e-ID method>
Order of precedence
Each of the above e-ID method options in order of precedence:
acr_valuesspecifies the chosen e-ID method
login_hintembeds the chosen e-ID method
- An HTTP header named
acr_valuescontains the chosen e-ID method
- The URL-path contains an encoded e-ID method value
Can’t make any of the options work for you?
Drop us a message on firstname.lastname@example.org with a description of your scenario if you are not able to make the above work for you.