Skip to main content

IdP scoping

IdP scoping allows you to define which eIDs to make available for authentication to your users.

One of the advantages of using IdP scoping is the ability to show only eIDs that are relevant to your users, thus shielding the other eIDs active in your Signicat account. This feature is also known as IdP discovery or IdP routing rules.

How it works​

Let's imagine a scenario where you have implemented a login button on your web application, registered it with Signicat eID Hub, and have configured multiple eIDs in your account, such as Norwegian BankID and eHerkenning.

When a user wants to log in to your app, they click the login button. With IdP scoping, you can automatically route the user to the appropriate eIDs (for example only eHerkenning) and shield them from seeing the other eIDs active in your account (in this case Norwegian BankID). You may want to do this for a multitude of reasons, such as geographical relevance.

How to skip the provider selection screen

If you specify only one eID in your request, you automatically redirect the user to the authentication page of the eID, thus skipping the provider selection screen.

IdP scoping allows you to control the following aspects of an authentication session:

  1. eID method scoping: Defines which eIDs are available for authentication to the user.
  2. Provider scoping: Further specifies the provider, bank or issuer to make available for an eID. For example, with iDIN you can choose to direct the end-user to one of or many of the issuing banks. Note that only certain eIDs support provider scoping.

The rest of this document describes and shows examples to handle both cases.

eID scoping​

To use IdP scoping, you provide the list of eIDs you want to offer as parameters in the authorisation request. How you specify the eIDs varies per authentication protocol. Here, select the tab of the authentication protocol used in your integration:

When using the OIDC, specify the eIDs you want to offer using the acr_values parameter in your authorisation request. In particular, use the idp key of the acr_values query parameter with the format acr_values=idp:idp_name,other_idp_name. For example, to display Email OTP and FTN to the end-user, the authorisation request could look like this:

https://<YOUR_SIGNICAT_DOMAIN>/auth/open/connect/authorize?
  &client_id=<OIDC_CLIENT_ID>
  &response_type=<GRANT_TYPE_CODE>
  &redirect_uri=<REDIRECT_URI>
  &scope=openid%20profile
  &state=<STATE>
  &code_challenge=ABC123
  &code_challenge_method=S256
  &acr_values=idp:otp-email,ftn

To learn more about acr_values, see the acr_values documentation.

When you start an authentication flow, the end-user will have the option to choose between Email OTP and FTN in the provider selection screen.

Provider selection screen

Provider selection screen

IdP scoping conditions

When using IdP scoping, you can only specify eIDs that are active in your account.

For an overview of the values supported for each eID, go to https://<YOUR_SIGNICAT_DOMAIN>/broker/idps. Use the value of the internalName property. You can view a list of values for the most common eIDs in the IdP scoping values section.

Skip IdP selection screen​

If you define only one eID with IdP scoping, then the end-user is automatically routed to the IdP-specific authentication page, thus automatically skipping the IdP selection screen during authentication.

For example, to automatically direct the end-user to SMS OTP, build your authorisation request as shown below. Select the tab according to the authentication protocol you want to use:

To automatically direct the end-user to SMS OTP with OIDC, define acr_values=idp:otp-sms in your authorisation request:

https://<YOUR_SIGNICAT_DOMAIN>/auth/open/connect/authorize?
  &client_id=<OIDC_CLIENT_ID>
  &response_type=<GRANT_TYPE_CODE>
  &redirect_uri=<REDIRECT_URI>
  &scope=openid%20profile
  &state=<STATE>
  &code_challenge=ABC123
  &code_challenge_method=S256
  &acr_values=idp:otp-sms

The examples shown above allow you to shield the end-user from seeing other eIDs that are active in your account.

Provider scoping​

Certain eIDs are comprised of a network of identity providers (or issuers), such as banks, that offer authentication to their own customers. You can provide your end-users with only a limited number of these identity providers when authenticating with a specific eID.

In the table below, you find the parameters available for each eID that supports provider scoping:

Here is how to define provider scoping in your authorisation request with the authentication protocol of your choice:

To control which providers you make available for each authentication session, you specify a key-value using the acr_values parameter.

For example, when authenticating end-users with the Finnish Trust Network (FTN), you can specify FTN providers with the ftn_idp parameter in the ACR values. To allow authentication only with Aktia Bank, pass the following query parameter in your authorisation request:

acr_values=ftn_idp:fi-aktia

For more examples and parameters, see the respective eID documentation.

IdP scoping values​

Below, you find an overview of the values you can use for IdP scoping with the most common eIDs supported by Signicat.

* The simulator is a tool for testing. Learn more in the simulator documentation.

Last updated:
On this page