Request parameters

​

Authorization endpoint

To start the login flow, you build an authorize request and redirect the user to the Idura Verify authorization endpoint (/oauth2/authorize). By including specific parameters (e.g. redirect_uri, scope, acr_values) in your request, you can control the authentication flow, customize the user experience, and request specific user data.

Assuming your Idura domain is acme-corp.idura.broker, a raw HTTP GET request looks like this (line breaks added for readability):

  GET /oauth2/authorize?
    client_id=urn:my:app:id&
    redirect_uri=https://my-app.com/callback&
    response_type=code&
    scope=openid&
    acr_values=urn:grn:authn:no:bankid&
    state=8a7b6c5d4e3f2g1h HTTP/1.1
  Host: acme-corp.idura.broker

A list of all supported authorize request parameters can be found below.

Parameter	Required	Description
client_id	Yes	Your application's unique identifier.
redirect_uri	Yes	The URL where the user will be redirected after authentication.
response_type	Yes	The type of credential Idura Verify will return to your application after the user successfully authenticates (typically, code).
scope	Yes	Used to request specific user claims. Must always include openid.
state	Recommended	An opaque string used to prevent CSRF attacks.
nonce	Recommended	An opaque string used to prevent replay attacks.
acr_values	No	Specifies which eID identity service(s) you want to invoke.
response_mode	No	Specifies the format of the response Idura Verify returns to your redirect URL.
login_hint	No	Used to control the runtime behavior and customize the user experience in several ways.
prompt	No	Specifies whether the user should be forced to re-authenticate, and allows you to manage consent.
code_challenge	PKCE only	Code challenge for the PKCE flow.
code_challenge_method	PKCE only	Hashing method used to create the code_challenge, e.g. S256.
request_uri	PAR only	A unique identifier of the request.
request	JAR only	Contains the JWT with JSON-encoded request parameters.

​

Token endpoint

To complete the authentication process and obtain an ID token, the client application sends an HTTP POST request to the Idura Verify token endpoint (/oauth2/token). The required parameters depend on the authorization flow.

Parameter	Required	Description
grant_type	Yes	The type of authorization flow being executed.
code	Authorization Code flow or PKCE	Authorization code received from the authorization endpoint.
redirect_uri	Authorization Code flow or PKCE	The URL where the user will be redirected after authentication. Must match the redirect_uri sent in the initial authorization request.
client_id	PKCE only	Your application's unique identifier.
code_verifier	PKCE only	A random string used to generate the code_challenge.
client_assertion	Private Key JWT only	A signed JWT used to authenticate your client instead of a client secret.
client_assertion_type	Private Key JWT only	The format of the assertion, must be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
auth_req_id	CIBA only	A unique identifier of the request.
headless_req_id	Headless only	A unique identifier of the request.

​

client_id

The unique identifier for your Idura application. You can find this value under your application's General settings in the Idura Dashboard.

​

redirect_uri

The URL where Idura will redirect the user's browser after authentication has been completed. This exact URL must be pre-registered as a Redirect URL in your application settings in the Idura Dashboard.

​

response_type

Denotes the kind of credential Idura Verify will return to your redirect_uri after the user successfully authenticates.

• Use code if you are integrating a traditional server-based web application (Authorization Code flow) or a public client using PKCE.
• Use id_token only for legacy single-page applications using the Implicit flow (or for debugging).

​

acr_values

Specifies the authentication method you want to trigger. For example, sending urn:grn:authn:dk:mitid:business will invoke Danish MitID Erhverv.

You can send multiple values separated by a space to trigger multiple authentication methods in a single request (e.g., acr_values=urn:grn:authn:se:bankid:same-device urn:grn:authn:dk:mitid:substantial).

Some eIDs have multiple acr_values to distinguish between a mobile and a web-based service, or to require different levels of assurance. Supported acr_values can be found in the Authorize URL Builder or in the individual eID articles.

Default acr_values and Method selector

If no acr_values are sent, Idura Verify will invoke the eID methods configured in the eID section of your application settings.

If multiple eID methods are triggered (either by passing multiple acr_values in the request or relying on your dashboard configuration), Idura will present the user with a selection screen listing all available eIDs.

​

state

An opaque arbitrary alphanumeric string generated by your application, which Idura will send back to your redirect_uri. You should verify that the returned state matches the one you sent to mitigate Cross-Site Request Forgery (CSRF) attacks. Learn more in our Security best practices guide.

​

nonce

An opaque arbitrary alphanumeric string generated by your application, which Idura will include in the ID Token. You should verify that the returned nonce matches the original one you sent to mitigate replay attacks. Learn more in our Security best practices guide.

​

response_mode

Specifies the format in which the result of a successful authentication will be delivered to your redirect_uri.

• Use queryto return the code/id_token as a query parameter.
• Use fragment to have it delivered on a URL fragment.
• Use form_post to have it posted back to your redirect_uri.

The default values are query for response_type=code and fragment for response_type=id_token.

​

scope

Defines which user attributes (claims) Idura Verify will include in the id_token issued to your application.

Every authorize request must include the openid scope value. Multiple values are separated by a whitespace (e.g., openid ssn address).

​

Scope strategies (dynamic vs. static):

How Idura handles requests for specific user data depends on your application's scope strategy.

• Dynamic strategy (default): Provides maximum flexibility. You must explicitly request the specific data you want in every authorize request. For example, sending scope=openid ssn will request the user's social security number.
• Static strategy: You only send scope=openid in your request. Idura will automatically return the data points you pre-configured for each eID via the dashboard.

You can change your application's scope strategy in the Idura Dashboard under the General tab of your application settings.

​

Supported scope values

When using dynamic scopes, the scope value must always contain the value openid, and it may also contain any of the following values: address, email, phone, birthdate, and ssn (availability depends on the specific eID provider).

You can see which values are supported for the various eIDs in the Authorize URL Builder or in the individual eID articles.

​

login_hint

The login_hint is a standard OAuth 2.0 request parameter Idura uses to customize the runtime behavior in several ways. We chose this approach as it is often possible to pass login_hint if you're integrating Idura Verify via an intermediary (e.g., Microsoft Entra ID or Auth0). It is also a fallback for cases where intermediaries do not allow you to pass values via standard OpenID Connect query parameters (most notably scope and acr_values).

login_hint can contain multiple values separated by a space.

See specific use cases where login_hint is used to specify the runtime behaviour or get around limitations:

• App switching
• Prefilled fields
• Quirks mode
• 'Dynamic' styling
• DK MitID for business
• Action specifiers
• End-user confirmation texts

​

Action specifiers

For Danish MitID and Swedish BankID (another-device flows), you can change the default "Log in" wording in the eID app by passing an action specifier:

• action:confirm
• action:accept
• action:approve
• action:sign
• action:login (default)

​

End-user confirmation texts (message)

For Danish MitID and Swedish BankID, you can display a custom text message directly inside the user's eID mobile app. The message must be base64-url-encoded and passed via message:BASE64URL(...text...).

• Danish MitID: The maximum length is 130 characters before base64 encoding.
• Swedish BankID: The maximum length is 1500 characters after base64 encoding.

​

prompt

Used to control the session behavior of your domain, defining whether the user will be forced to re-authenticate. Also allows you to manage end-user consent. Idura Verify supports the following values:

• Omitted (default): Reuses an existing session if one is available. If no session exists, the user is prompted to authenticate.
• none: Requires an existing active session. If the user is not already logged in, authentication fails.
• login: Forces the user to re-authenticate, even if they already have an active session.
• consent: Might force the user to grant consent.
• consent_revoke: Allows the user to revoke previously granted consent, for instance, via a "forget-me" link.

More information is available in our SSO guide and Authorize URL Builder.

​

code_challenge

Required for the PKCE flow. The code_challenge is a base64URL-encoded hash of a random string (the code_verifier) generated by your client application.

​

code_challenge_method

Required for the PKCE flow. This tells Idura Verify which hashing method you used to create the code_challenge (e.g. S256).

​

request_uri

Used in Pushed Authorization Requests (PAR) to pass a reference to the authorization request payload, keeping the actual request parameters out of the browser's query string.

​

request

Used in JWT-secured Authorization Requests (JAR). This parameter contains a Request Object – a signed JWT whose claims hold the JSON-encoded authorization request parameters. This acts as a security enhancement to prevent parameter tampering.

​

grant_type

Sent to the token endpoint to specify the authorization flow type being executed. Idura Verify supports the following values:

• authorization_code (for Authorization Code flow and PKCE)
• urn:ietf:params:oauth:grant-type:ciba (for CIBA flow)
• urn:idura:params:grant-type:headless (for Headless flow)

​

code

The authorization code received from the authorization endpoint after a successful user login. Sent to the token endpoint to be exchanged for tokens during the Authorization Code and PKCE flows.

​

code_verifier

Required at the token endpoint for the PKCE flow. This is the original random string you generated before hashing it into the code_challenge.

​

auth_req_id

A unique request identifier returned by Idura Verify that must be included in the token request during the CIBA flow.

​

headless_req_id

A unique request identifier returned by Idura Verify that must be included in the token request during the Headless flow.

​

client_assertion

The signed JWT used for Private key JWT client authentication at the token endpoint instead of a static client secret.

​

client_assertion_type

Used for Private key JWT client authentication. When using a client assertion, this parameter must be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer.