Skip to main content

Prefilling user information

When your app already knows some information about a specific user, you can include such information as a hint in an authentication process.

Prefilling allows you to pre-populate user data in the request to an eID provider. Typically, you reuse information that you have previously collected such as an email address, phone number or username. Passing data as a hint either displays the information to the user on screen or automatically skips a step in the authentication flow.

Here are some advantages of prefilling user information:

  • Simplify and enhance the user experience within your app.
  • Offer more user-centric, intuitive, and efficient authentication flows.
  • Save the user time by pre-populating or skipping screens.
  • Ensure that an authentication request is tailored to a specific user associated with the data you pass to the identity provider.

How it works​

Let's suppose that you already know the national identity number (NIN) of a user trying to authenticate with your app. For example, you collected the NIN in a previous step in the app or keep it stored in a database.

A flow where you pre-fill user information would look like this:

  1. You already know the NIN of the user.
  2. The user wants to authenticate with your app.
  3. You pass the NIN as a hint to the identity provider (eID).
  4. The identity provider pre-populates the NIN on the login screen.
  5. The user reviews the NIN and proceeds, instead of having to enter the value manually.
Security considerations

When prefilling user information, developers must be aware of security risks and implement mitigation strategies to protect user data and application integrity. Learn more about it in the Security considerations section below.

How to pre-fill user information​

To dynamically pre-fill user data, you specify the values as parameters in the authorisation request to the eID. How you pass data in your request varies per authentication protocol and provider.

To view how to use prefilling with an authentication protocol, select the appropriate tab below:

When using OpenID Connect (OIDC), you pass user data with the login_hint parameter.

The format is a space-separated list of key-value pairs: login_hint=key1:value1 key2:value2. For example, use login_hint=email:email%40example.com to pass the email address of the end-user to the eID. Note how %40 is the URL encoded version of the @ sign.

For example, to suggest the email address of the end-user in the Email OTP authentication screen your authorisation request might 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%20idp-id
  &state=<STATE>
  &code_challenge=ABC123
  &code_challenge_method=S256
  &acr_values=idp:email-otp
  &login_hint=email:email%40example.com
Format: URL encoding

To ensure the property value is correctly interpreted in your OIDC authorisation request, you should format it using URL encoding. For example, use the URL encoded (percent encoding) %2B447700900000 string to represent the +44 7700900000 phone number.

Learn more about login_hint in the login_hint documentation.

In the authentication flow, the end-user views the email address already pre-populated on the screen. For example, when prefilling the email address using Signicat Email OTP, the authentication screen looks like this:

Email address dynamically pre-filled when the end-user authenticates with Email OTP

Email address dynamically pre-filled when the end-user authenticates with Email OTP

Note that certain eIDs might instead skip one of the screens/steps in the flow. For example, if you pre-fill the NIN in your request to Norwegian BankID, the page where end-users typically enter their NIN is skipped by default. Instead, the end-user is directed to the next page in the flow, where they enter their password. This is to prevent that the NIN changes.

For an overview of supported prefilling properties, see the next section below.

Supported properties​

The table below shows what properties Signicat supports for prefilling user information in an authorisation request:

Note: SAML 2.0 requires the following format: signicat:prefilled:<property>. For example, signicat:prefilled:email.

Coverage

Note that certain identity providers support only a subset of the properties listed in the table above. For an overview of the values supported by an eID, see the eIDs documentation.

Security considerations​

A live implementation in production should adhere to the highest security standards. When setting up your app to pre-fill user information, keep the following security considerations in mind:

Validate input and output​

Validating input consistency helps prevent potential security issues, such as user impersonation or man-in-the-middle attacks.

When prefilling user information in the authorisation request, you must verify that the value you prefill matches the corresponding value returned by the eID in the response. For example, if you prefill user@example.com in the login hint, confirm that the same value is included in the response from the eID.

If there is a mismatch between the prefilled value and the response value, your app should reject the session and prompt the user to authenticate again. Do not rely only on the prefilled value to identify a user.

Use signed requests and Pushed Authorization Requests (PAR)​

When setting up your app for prefilling user information with OIDC, the following measures help you mitigate any security risks:

Other resources​

Below you find examples of prefilling user information:

Last updated:
On this page