OIDC request parameters

The E-Consent service uses OpenID Connect (OIDC)​ as the integration protocol. Below is an explanation of parameters for authorization and token retrieval.

See http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest for specification of some of the mandatory OIDC parameters.​


Authorization endpoint

Use the discovery endpoint to find the URL for the authorization endpoint.

[E-Consent host]/e-consent/.well-known/openid-configuration


Parameter​Description
​response_type​Should always be code.​
​client_id​Identifier of the client, agreed with Nets.
​redirect_uri​URI that the response will be sent to when authorization is finished. Must be from a list of preregistred URI's for this client.
​scope​Space separated list of scopes that client is requesting authorization for. openid must be included for all requests. To receive refresh tokens, include offline_access. A specific scope identifying the consent type should also be included. The value for this scope is agreed with Nets.
nonce​​String value used to associate a client session with an ID Token, and to mitigate replay attacks. Must be unique per request per client.
​promptlogin for non offline_access scope, and consent for offline_access scope.
state​​Opaque value used to maintain state between the request and the callback.
​ui_localesSpace separated list of BCP47 language tags​.
​request​A serialized, signed JWT (JWS) where the payload contains all query parameters (the ones listed above) and a few E-Consent specific parameters. See explanation below.

Description of parameter request

To make it impossible to change the request before the user is redirected, it is also mandatory to include the parameters above in a request object. The OIDC parameters must have exactly the same value in both places where they are listed. In E-Consent, the request object (not the request as a whole, only the request parameter that is named request) is a signed JWT (JWS). As part of the regular validation process, it is verified that the signing of the object is done by the client.

The JWT payload of the request parameter is a copy of all the top-level parameters in addition to the a few additional fields, and the claims. All content is represented as JSON.

Additional fields in JWT payload:

Field​Description
​​amr

eID displayed to the user.
Possible values: [NO_BANKID, NO_BANKID_MOB, DK_NEMID, DK_NEMID_OPENSIGN, SE_BANKID, FI_TUPAS, FI_MOBIILIVARMENNE]
Must be exactly one for signing flow, can be zero, one, or many for identification flow.

​​forcebank​Only relevant if FI_TUPAS is used as eID. This setting pre-selects one of the Finnish Bank ID providers. Possible values: [NORDEA, OPBANK, DANSKE, HANDELSBANKEN, ALAND, SBANK, AKTIA, POPBANK, SAVINGSBANK, OMASP]
​custom_claims

​A JSON object in the following format:
"custom_claims":{
   "<TOKEN_NAME>":{
     <CLAIMS>
   }

The token name is configured on Nets' side. It contains the consent text in different languages and can support some variables. The values for those variables is defined in custom_claims. Example:

"custom_claims":{
   "myinsurance-token":{
     "thirdparty": "InstantInsurance.com",
     "validdays": 1
   } 

 

Token endpoint

Use the discovery endpoint to find the URL for the token endpoint.
[E-Consent host]/e-consent/.well-known/openid-configuration
 
​Parameter​Description
​grant_typeauthorization_code or refresh_token, depending on what type the code is.
code​​Either the authorization code returned from authorization endpoint, or refresh token returned from token endpoint. Must match the specified grant_type.
​redirect_uri​Same as in request to authorization endpoint.