Authorization server 

This section describes the authentication/authorization API for the CONNECT ID authorization server, which is an implementation of the OAuth 2.0 and OpenID Connect protocols. The description addresses clients implementing the authorization code flow.

User authorization 

Get user authorization
/oauth/authorize{?response_type,client_id,redirect_uri,scope,state,prompt,max_age,ui_locales,login_hint,acr_values,claims}

Direct the user to this endpoint if you want to initiate the authentication/authorization flow in CONNECT. When the user is authenticated and has authorized that the client may access their protected resources (represented by scopes), the browser will be redirected to the URI you have specified in the call with an authorization code. The authorization code can be used to get an access token and a refresh token via the get access token endpoint. The access token can subsequently be used to access the end user’s protected resources on resource servers and the access may be refreshed using the refresh token.

  • Parameters
  • response_type
    string (required) Example: code

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

    client_id
    string (required) Example: mycompany-myapp-clientplatform

    The client id given to the client by CONNECT.

    redirect_uri
    string (required) Example: https://client.example.com/cb

    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.

    scope
    list (required) Example: openid profile email

    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.

    state
    string (optional) Example: l432halkjfdsdsa

    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.

    prompt
    string (optional) Example: none

    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.

    max_age
    int (optional) Example: 3600

    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.

    ui_locales
    list (optional) Example: bn en

    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.

    login_hint
    string (optional) Example: +60161234560

    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.

    acr_values
    string (optional) Example: 2 1

    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.

    claims
    string (optional) Example: {"id_token":{"phone_number":{"essential":true}}}

    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
        }
      }
  • Response  303
  • If authentication and authorization is successful, the authorization server redirects the user agent to the client callback endpoint specified in the redirect_uri parameter with an authorization code. The redirect has a header similar to [1].

    If an error happens (except if there is something wrong with the client id or redirect URI parameters or login session has timed out), the authorization server redirects the user agent to the client callback endpoint specified in the redirect_uri parameter with an error code and description. The redirect has a header similar to [2].

    Headers
    Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz [1]
    Location: https://client.example.com/cb?error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request&state=xyz [2]
  • Response  400
  • If there was something wrong with the client id or redirect URI parameters or the login session has timed out, it will not be possible and/or advisable to redirect back to client with an error code. The authorization server will for these cases reply with an HTML error page.

    Headers
    Content-Type: text/html

Token 

This endpoint allows you to get an access token, a refresh token and an ID token either based on the authorization code acquired from the user authorization endpoint or based on the refresh token from a previous call to this API.

Confidential clients need to authenticate with the client ID and client secret using HTTP Basic authentication, see the Authorization header in the request specifications below. Public clients (which are not issued a client secret) need to supply the client ID in the client_id parameter instead.

The response for these calls is a JSON object containing the following attributes:

  • access_token string

    An access token, which is a short-lived credential for the client. You can use this to access protected resources on resource servers on the user’s behalf.

    Example: 8gvoQq9ernbhOL4ztHAkZcTnYph

  • token_type string

    The type of access token you are getting.

    Example: Bearer

  • scope string

    The list of scope values the access token will work for.

    Example: openid profile email

  • expires_in string

    The time in seconds until the access token expires.

    Example: 3600

  • refresh_token string

    A refresh token, which is a long-lived credential for the client. If you try to use the access token, but it is no longer valid, you can refresh the access token using this refresh token.

    Example: Vb5tUNzVENFjFCKkFBOsTa6mRDk

  • id_token string

    An ID token is a JSON Web Token (JWT) containing information about the authentication performed by the authorization server (OpenID Provider). It asserts the identity of a user in a signed and verifiable way, resembling the concept of an identity card in a digital form, which can be verified by the client. This field is only present if the openid scope value was provided to the user authorization call.

    Example (with extra line breaks for display purposes only):

    eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.
      eyJhdXRoX3RpbWUiOjE0MzIyOTM2ODEsImV4cCI6MTQzMjI5NzU4MSwic3ViIjoi
      NTk5OTUwNzM3NTIwMTk4MDQxNiIsImF1ZCI6InRlc3QtY2xpZW50IiwiaXNzIjoi
      aHR0cDpcL1wvbG9jYWxob3N0OjgxMDdcL29hdXRoIiwidGRfc2xzIjpmYWxzZSwi
      aWF0IjoxNDMyMjkzOTc3LCJhY3IiOiIxIn0.
      QP_opLXIU2ct7p94tuAuU9EjPKqB-7WVvzv1TjRh9mMYX8goiHV84cqhc00f4PNU
      lMKk5T-uEY4C_AOF4y3z5kkRkC9T_Y_A_yToGYmX8WmGGKvAH78EYkBe48H6POt9
      kVj31u1w_wMFvzlcGTUMFL7cg7uxTtgxyc4sJjiufMM
Get access token
/oauth/token

To get an access token and a refresh token using an authorization code, the client may send the following request. This is typically called from the redirection endpoint of the client after getting the authorization code as a result of successfully performing the user authorization grant flow.

  • Parameters
  • `grant_type`
    string (required) Example: authorization_code

    The type of grant used to get tokens. Use authorization_code.

    code
    string (required) Example: lkj;d24lkjnwerlkj23l4kj

    The authorization code you received in the callback to your redirect URI in the user authorization call.

    redirect_uri
    string (required) Example: https://client.example.com/cb

    The redirect URI specified in the user authorization call.

    client_id
    string (optional) Example: mycompany-myapp-clientplatform

    The client id given to the client by CONNECT. This parameter is required for public clients.

  • Request
  • Headers
    Content-Type: application/x-www-form-urlencoded
    Accept: application/json
    Authorization: Basic <Base64 encoding of client_id:client_secret>
    Body
    grant_type=authorization_code&code={code}&redirect_uri={redirect uri}&client_id={client id}
  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "access_token": "8gvoQq9ernbhOL4ztHAkZcTnYph",
      "token_type": "Bearer",
      "scope": "[assigned scope]",
      "expires_in": 3599,
      "refresh_token": "Vb5tUNzVENFjFCKkFBOsTa6mRDk"
    }
  • Response  400
  • Headers
    Content-Type: application/json
    Body
    {
      "error": "invalid_request",
      "error_description": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed"
    }
  • Response  401
  • Headers
    Content-Type: application/json
    WWW-Authenticate: Basic realm="Telenor Digital Authorization Server"
    Body
    {
      "error": "invalid_client",
      "error_description": "Client authentication failed"
    }
Refresh access token
/oauth/token

If the access token used by the client has expired, a new one may be requested using the refresh token returned earlier. Note that the authorization server issues a new refresh token as well to replace the old one.

  • Parameters
  • `grant_type`
    string (required) Example: refresh_token

    The type of grant used to get tokens. Use refresh_token.

    refresh_token
    string (required) Example: Vb5tUNzVENFjFCKkFBOsTa6mRDk

    The refresh token to use to generate a new access token.

    client_id
    string (optional) Example: mycompany-myapp-clientplatform

    The client id given to the client by CONNECT. This parameter is required for public clients.

  • Request
  • Headers
    Content-Type: application/x-www-form-urlencoded
    Accept: application/json
    Authorization: Basic <Base64 encoding of client_id:client_secret>
    Body
    grant_type=refresh_token&refresh_token={refresh token}&client_id={client id}
  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "access_token": "8gvoQq9ernbhOL4ztHAkZcTnYph",
      "token_type": "Bearer",
      "scope": "[assigned scope]",
      "expires_in": 3599,
      "refresh_token": "Vb5tUNzVENFjFCKkFBOsTa6mRDk"
    }
  • Response  400
  • Headers
    Content-Type: application/json
    Body
    {
      "error": "invalid_grant",
      "error_description": "The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client"
    }
  • Response  401
  • Headers
    Content-Type: application/json
    WWW-Authenticate: Basic realm="Telenor Digital Authorization Server"
    Body
    {
      "error": "invalid_client",
      "error_description": "Client authentication failed"
    }

Token information 

The authorization server offers a TokenInfo endpoint to provide more information about the various tokens it supplies in addition to validating them at the time of the request to this endpoint. At the moment, the endpoint can validate access tokens, ID tokens, and logout tokens.

Verify access token
/oauth/tokeninfo{?access_token,id_token,logout_token}

Resource servers that receive access tokens from clients must validate the token before trusting it and returning protected resources. This endpoint is a very convenient starting point for doing such validation, even though it requires a network call. Alternative ways of validating access tokens may be considered if the client supports back-channel logout functionality, since the client and/or resource servers may rely on the back-channel logout notification rather than “polling” this endpoint in order to detect that the access token has become invalid, e.g. because of a logout situation.

If the resource server does not receive a 200, it should fail back to the client, so that the client can use the refresh token to get a new access token. The resource server response should be implemented according to RFC 6750, since access tokens are of “bearer” token type. More specifically, errors should be reported back to the client according to RFC 6750, section 3.1, which means that each type of error response from the TokenInfo endpoint needs to be transformed into an appropriate error code in the specified format. Also, if the scope is not sufficient to get access to the protected resource, it should fail back to the client with error code insufficient_scope, according to RFC 6750, section 3.1.

  • Parameters
  • access_token
    string (required) 

    Access token to get info about.

  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "clientid": "<your client id>",
      "scope": "<scope for access token>",
      "userid": "<the user’s id>",
      "ttl": 3447
    }
  • Response  400
  • Headers
    Content-Type: application/json
    Body
    {
      "error": "invalid_token",
      "error_description": "Token does not exist, or it has expired"
    }
Verify ID token
/oauth/tokeninfo{?access_token,id_token,logout_token}

This endpoint can be used to validate the signature of an ID token and decode its contents. This function is only provided as a convenience while developing clients and is not supposed to be used in production code because of the extra network call. The ID token is self-contained and should be decoded and validated locally within the client without using this endpoint, see ID token validation. Note that the claims in the ID token must be validated by the client prior to its use according to the OpenID Connect Core spec, section 3.1.3.7.

  • Parameters
  • id_token
    string (required) 

    ID token to get info about.

  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "auth_time": 1432293681,
      "exp": 1432297581,
      "sub": "5999507375201980416",
      "aud": [
        "test-client"
      ],
      "iss": "https://connect.telenordigital.com/oauth",
      "td_sls": false,
      "iat": 1432293977,
      "acr": "2",
      "amr": [
        "UID_PWD"
      ],
      "td_au": "4799989999",
      "name": "John Doe",
      "locale": "en-US",
      "email": "john.doe@example.com",
      "email_verified": true,
      "phone_number": "4799989999",
      "phone_number_verified": true
    }
  • Response  400
  • Headers
    Content-Type: application/json
    Body
    {
      "error": "invalid_token",
      "error_description": "Token can not be verified"
    }
Verify logout token
/oauth/tokeninfo{?access_token,id_token,logout_token}

This endpoint can be used to validate the signature of a logout token and decode its contents. This function is only provided as a convenience while developing clients and is not supposed to be used in production code because of the extra network call. The logout token is self-contained and should be decoded and validated locally within the client without using this endpoint. Note that the claims in the logout token must be validated by the client prior to its use according to the OpenID Connect Back-Channel Logout spec, section 2.6.

  • Parameters
  • logout_token
    string (required) 

    Logout token to get info about.

  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "iss": "https://connect.telenordigital.com/oauth",
      "sub": "5999507375201980416",
      "aud": [
        "test-client"
      ],
      "iat": 1432293977,
      "jti": "hvov4GJ4vaW5JTW1YhqVJ9K9nK8",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      },
      "sid": "btG3F4WqClfMUf5SE5X59jiRitI"
    }
  • Response  400
  • Headers
    Content-Type: application/json
    Body
    {
      "error": "invalid_token",
      "error_description": "Token can not be verified"
    }

User information 

It is possible to retrieve basic user information using this endpoint. The standard user claims returned are dependent on which scope values and/or claims were requested in the scope and/or claims parameters in the user authorization call and the amount of information stored in the user profile. Note that it is possible to get the same claims in the ID token, so that the extra round-trip to this endpoint can be avoided.

The following table shows the mapping between the different scope values that can be requested and claims that will be returned. Note that the “sub” claim is always present.

Scope value Claims
profile name, locale
email email, email_verified
phone phone_number, phone_number_verified
Get UserInfo
/oauth/userinfo
  • Request
  • Headers
    Accept: application/json
    Authorization: Bearer <access token>
  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
        "sub": "[the user's id]",
        "name": "[the user's name]",
        "locale": "[the user's locale]",
        "email": "[the user's preferred email address]",
        "email_verified": [true/false],
        "phone_number": "[the user's preferred phone number]",
        "phone_number_verified": [true/false]
    }
  • Response  401
  • If the authorization server is unable to validate the access token supplied in the authorization header, it will reply with an HTML error page with a WWW-Authenticate response header field, potentially with additional information on why the authentication failed. See below for an example of a protected resource request with an authentication attempt using an expired token.

    Headers
    Content-Type: text/html
    WWW-Authenticate: Bearer realm="Telenor Digital Resource Server", error="invalid_token", errorDescription="The access token is expired, revoked, malformed or otherwise invalid"

Revoke token 

Revoking a token makes sure that the token can no longer be used.

If for some reason the logout endpoint is not used for logout, the access token and refresh token known to the client should be deleted from client storage and provided to this revoke endpoint when the tokens are no longer needed.

Confidential clients need to authenticate with the client ID and client secret using HTTP Basic authentication, see the Authorization header in the request specifications below. Public clients (which are not issued a client secret) need to supply the client ID in the client_id parameter instead.

Revoke token
/oauth/revoke
  • Parameters
  • token
    string (required) Example: 5Cc4MoBUebsrQJmjZ5kf3DPD0pT

    The token to revoke

    client_id
    string (optional) Example: mycompany-myapp-clientplatform

    The client ID in the case of public clients

  • Request
  • Headers
    Content-Type: application/x-www-form-urlencoded
    Authorization: Basic <Base64 encoding of client_id:client_secret>
    Body
    token={token}&client_id={client_id}
  • Response  200
  • Response  400
  • Headers
    Content-Type: application/json
    Body
    {
      "error": "unauthorized_client",
      "error_description": "The client is not authorized to perform this operation"
    }
  • Response  401
  • Headers
    Content-Type: application/json
    WWW-Authenticate: Basic realm="Telenor Digital Authorization Server"
    Body
    {
      "error": "invalid_client",
      "error_description": "Client authentication failed"
    }

User logout 

To log out a user from the single sign-on (SSO) solution embedded in the authorization server, two endpoints are available for a client to use. These endpoints are only necessary to use for clients that have SSO enabled.

A logout will invalidate the current CONNECT SSO session. For web clients, access and refresh tokens associated with the SSO session on the current user agent will typically be revoked as well, while for native apps, tokens will typically not be revoked. This is a security feature for web clients, for which single logout (SLO) is expected by end users. Native apps, on the other hand, are considered more self-contained and run on devices that are considered more personal. Long-time access without occasional logins caused by SLO is therefore expected for native apps.

Logout using a browser
/oauth/logout{?client_id,post_logout_redirect_uri,state,ui_locales}

To initiate a browser logout, a client may redirect the browser to this endpoint. After the authorization server has processed the logout, the user is redirected with the supplied state to a pre-configured post logout redirect URI. This endpoint is the preferred way to log out if the client service is currently being consumed on a web browser.

  • Parameters
  • client_id
    string (required) Example: mycompany-myapp-clientplatform

    The client id given to the client by CONNECT.

    `post_logout_redirect_uri`
    string (optional) Example: https://client.example.com/logout_cb

    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.

    state
    string (optional) Example: as3k86jg5sh3u6f

    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.

    ui_locales
    list (optional) Example: bn en

    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.

  • Response  303
  • If logout is successful, the authorization server redirects the user agent to the client callback endpoint specified in the post_logout_redirect_uri parameter. The redirect has a header similar to [1].

    If an error happens (except if there is something wrong with the client id or redirect URI parameters), the authorization server redirects the user agent to the client callback endpoint specified in the post_logout_redirect_uri parameter with an error code and description. The redirect has a header similar to [2].

    Headers
    Location: https://client.example.com/logout_cb?state=xyz [1]
    Location: https://client.example.com/logout_cb?error=invalid_request&error_description=The+request+is+missing+a+required+parameter,+includes+an+invalid+parameter+value,+includes+a+parameter+more+than+once,+or+is+otherwise+malformed&state=xyz [2]
  • Response  400
  • If there was something wrong with the client id or redirect URI parameters, it will not be possible and/or advisable to redirect back to client with an error code. The authorization server will for these cases reply with an HTML error page.

    Headers
    Content-Type: text/html
Logout using an access token
/oauth/logout{?client_id,post_logout_redirect_uri,state,ui_locales}

To perform a token-based logout, a client may POST directly to this endpoint using a valid, unexpired access token. No particular scope is required. This endpoint is useful if the user is not currently using a web browser, for instance in a native mobile app context.

  • Request
  • Headers
    Content-Type: application/x-www-form-urlencoded
    Authorization: Bearer <Valid access token>
  • Response  200
  • Headers
    Content-Type: application/json
  • Response  401
  • If the authorization server is unable to validate the access token supplied in the authorization header, it will reply with an HTML error page with a WWW-Authenticate response header field, potentially with additional information on why the authentication failed. See below for an example of a request with an authentication attempt using an expired token.

    Headers
    Content-Type: text/html
    WWW-Authenticate: Bearer realm="Telenor Digital Resource Server", error="invalid_token", errorDescription="The access token is expired, revoked, malformed or otherwise invalid"

JWK set endpoint 

The JSON Web Key Set document for the authorization server is available via the JWK Set endpoint according to the OpenID Connect discovery specification. The JWK Set document contains public keys which can be used to validate ID token (and logout token) signatures.

Please note that the authorization server may rotate keys, so that if an ID/logout token is signed with an unknown key ID (kid in the JSON Web Token header of the token), the client needs to re-fetch the public key set from this endpoint.

Get JWK set
/oauth/public_keys.jwks
  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "keys": [
        {
          "alg": "RS256",
          "e": "AQAB",
          "kid": "1",
          "kty": "RSA",
          "n": "lxcvUaGEm5wyJDLHy7EuY_TyYiKzUl4E124PxVlAlOE7LG1sWEjdtaUkLbPF25CkmpNtG9cUhWJhFirsHt4QIMlhfL88DZvyEQwb8nZwUKat7Se4WdDw0FYkddo6rgrBEo5-sjtbc1WuQbRHf4cBn7BVX8T72ZsQcSNqI6CwLQc",
          "use": "sig"
        }
      ]
    }

OpenID Connect configuration endpoint 

The CONNECT ID authorization server supports configuration discovery from the OpenID Connect configuration endpoint according to the OpenID Connect discovery specification. The only thing the clients need to know is the issuer location (ID) of the authorization server.

Get OpenID Connect configuration
/oauth/.well-known/openid-configuration
  • Response  200
  • Headers
    Content-Type: application/json
    Body
    {
      "issuer": "https://connect.telenordigital.com/oauth",
      "authorization_endpoint": "https://connect.telenordigital.com/oauth/authorize",
      "token_endpoint": "https://connect.telenordigital.com/oauth/token",
      "userinfo_endpoint": "https://connect.telenordigital.com/oauth/userinfo",
      "jwks_uri": "https://connect.telenordigital.com/oauth/public_keys.jwks",
      "scopes_supported": [
        "openid",
        "profile",
        "email",
        "address",
        "phone",
        "id.user.read",
        "id.user.write",
        "id.user.email.read",
        "id.user.phone.read",
        "id.user.right.read",
        "id.user.right.use",
        "id.user.sub.read",
        "id.user.account.read",
        "payment.transactions.read",
        "payment.transactions.write",
        "payment.agreements.read",
        "payment.agreements.write"
      ],
      "response_types_supported": [
        "code"
      ],
      "grant_types_supported": [
        "refresh_token",
        "authorization_code"
      ],
      "subject_types_supported": [
        "public",
        "pairwise"
      ],
      "id_token_signing_alg_values_supported": [
        "none",
        "RS256"
      ],
      "service_documentation": "http://docs.telenordigital.com",
      "ui_locales_supported": [
        "bg",
        "bn",
        "da",
        "en",
        "hu",
        "id",
        "ms",
        "my",
        "no",
        "sr-Latn-ME",
        "sr-Latn-RS",
        "sv",
        "th",
        "ur",
        "zh-Hans"
      ],
      "claims_parameter_supported": true,
      "request_uri_parameter_supported": false,
      "end_session_endpoint": "https://connect.telenordigital.com/oauth/logout",
      "backchannel_logout_supported": true,
      "backchannel_logout_session_supported": true
    }

© 2017 Telenor Digital AS