The CONNECT authentication and authorization API

The response type you want from the authentication/authorization call. Use code.

The client id given to the client by CONNECT.

The URI you want the user to be redirected to after authentication and authorization. If authentication and authorization was successful, you will get an authorization code to be used for the /token endpoint. If not, you will get an error including an error code and a description. Note that the error code and description are suitable for debugging by client developers, but not to be displayed to end users.

A space-delimited list of scope values for authorization. If you want to use OpenID Connect, you must pass openid as one of the scope values.

Opaque value used to maintain state between the request and the callback (redirect URI). The parameter may be used to remember the state of the user in the client. The parameter must be used for preventing cross-site request forgery attacks for the callback endpoint, by cryptographically binding a value in the state with a session on the client. This can e.g. be done by storing a cryptographically random value as a session id in the client and use a cryptographic hash of the session id in this parameter.

A space-delimited list of string values that specifies whether the authorization server is allowed to prompt the end user for re-authentication and consent. Supported values are none, login, and no_seam.

• none: Try to get the end user logged in without user interaction (prompt). If the user is required to log in or to give consent, login_required or consent_required errors will be returned, respectively. If no prompt is required, e.g. if the end user is already logged in via SSO and giving consent is not necessary, an authorization code will be delivered to the client. This prompt value cannot be requested in combination with any of the other prompt values.

• login: Force explicit login. This will override potential automatic login through header enrichment or a valid SSO session.

• no_seam: Force login to happen without header enrichment (not seamless). This will not override potential automatic login through a valid SSO session, but will make sure that no header enrichment is used neither to log in or pre-fill username.

Maximum Authentication Age. This parameter does only have effect if the client has been configured to use single sign-on (SSO) functionality. It makes it possible for the client to specify maximum allowable elapsed time in seconds since the last time the end user was actively authenticated. If this time has passed, the authorization server must re-authenticate the end user. Please note that the authorization server has separate policies on when to require the end user to authenticate actively based on authentication age and SSO session usage.

A space-delimited list of locale values you want the user to get user-facing information in, e.g. for login, consent, and error pages. The elements should be ordered by degree of preference, with the most preferred locale first. Consult the configuration endpoint for a list of current possible locales.

Hint to the authorization server with MSISDN and/or email address to pre-fill the login form. Multiple hints can be provided in the same request.

A space-delimited list of integers that specify the Authentication Context Class Reference values that the authorization server is being requested to use for processing this authentication request, with the values appearing in order of preference. See the ‘acr’ claim documentation in the OpenID Connect Core spec, section 2 for more information on this. This parameter will restrict what authentication methods the user is allowed to use. In this authorization server, “ACR” is defined to be equivalent with “Levels Of Assurance” as specified in the ISO/IEC 29115:2013 standard. Therefore the set of legal values for this parameter is the integers 1 through 4. The level of assurance (LoA) satisfied by the authentication performed is returned as the ‘acr’ claim value in the ID token. This claim should always be checked if this parameter is used to ensure the level of assurance used in the authentication is satisfactory to the client. This is because the authorization server might choose not to use the provided ACR values. The following is a list of what kind of authentication method to expect for various ACR values:

• 1 Unsafe single-factor authentication, typically a possession factor. The possession factor is typically related to a mobile phone. Example: Header enrichment or PIN round-trip.

• 2 Single-factor authentication, typically a knowledge factor. Example: Password prompt.

• 3 Multi-factor authentication, typically a possession and a knowledge factor. Example: Password prompt and PIN round-trip. Not supported.

• 4 Multi-factor authentication with additional security requirements, e.g. in-person identity proofing for human entities. Not supported.

The ‘claims’ parameter in addition to the ‘scope’ parameter controls the standard user claims that are returned at the userinfo endpoint and in the ID token. It is a URI-encoded JSON object detailing what claims to request, where they should be returned, and if they are essential or not. The current implementation will return the claims both in the userinfo endpoint and the ID token, no matter for which of these locations the claims were specified to be returned. This implementation detail may change in the future and clients should therefore not rely on claims to be returned in a specific location without it being requested in the claims parameter. Note that for the userinfo endpoint, the claims returned will also always be dependent on the requested scope values in the scope parameter. If a claim is denoted to be essential, the user might be prompted to input this information during login if the information is not available. This can for example be used for making sure that phone number and/or email address is present. The available claims to request are the ones associated with the OpenID Connect scope values. Unknown claims will be ignored. The structure of the JSON object (and examples) are available in the OpenID Connect Core spec, section 5.5. Please note that the current implementation has the following limitations: A. Only claims available at the userinfo endpoint are supported. B. Requesting claims to be essential is only supported for the ‘email’ and ‘phone_number’ claims. C. Requiring claims to be returned with a certain value or one of a set of values is not supported. Examples (including spaces and line breaks for display purposes):

• Request that the logged in user has set an email address and that the user’s preferred email address is returned in the ID token:

  {
    "id_token": {
      "email": {
        "essential": true
      }
    }
  }

• Request that claims related to the preferred email address are returned in the userinfo endpoint (equivalent to using the ‘email’ scope value):

  {
    "userinfo": {
      "email": null,
      "email_verified": null
    }
  }

Access token to get info about.

ID token to get info about.

Logout token to get info about.

The client id given to the client by CONNECT.

The URI to redirect to after logout. Please note that the post logout redirect URI must be configured for the client in the authorization server beforehand, much like the redirect URI for the authorization endpoint, and that the post_logout_redirect_uri parameter simply forces the authorization server to pick a specific one.

Opaque value used to maintain state between the request and the callback (post logout redirect URI). The parameter may be used to remember the state of the user in the client.

A space-delimited list of language tags you want the user to get user-facing information in for potential error pages. The elements should be ordered by degree of preference, with the most preferred locale first. Consult the configuration endpoint for a list of current possible locales.