Guide
TrainingSupportCommunity

OpenID Connect concepts and terminology

Suggest Edits

OpenID Connect concepts

Main participants in the OIDC protocol and a role of EAA identity provider (IdP):

  • End user. The end user is the entity for whom we are requesting identity information. In OAuth 2.0 this refers to the resource owner. One of the resources they own is their own identity.

  • Relying party (RP). The client application that supports OAuth 2.0 and relies on the OpenID provider to authenticate the user and request claims about that user. In this case, it's the custom SaaS application or access application in EAA is the RP or client.

  • OpenID provider (OP). The OpenID provider is an OAuth 2.0 authorization server which offers authentication as a service. It ensures the user is authenticated and provides claims about the user and the authentication event to the relying party. The identity provider provides the relying party information about the user through identity tokens. When you add the application in EAA, you configure EAA or the ​Akamai​ identity provider as the OP.

Different types of Tokens are exchanged between the participants to verify the identity or provide access permissions. Tokens establish a user's identity during a transaction. Common token types are supported:

  • ID token. Similar to a ID card or passport, it contains many required attributes or claims about the user. It is a JSON web token (JWT) digitally signed using a JSON web signature for a high-level of security.

  • Access token. Gives permission to the client application to obtain end-user owned resources from a resource server. It is an opaque token that is validated by fetching user claims from userInfo endpoint.

The claims and scopes are used to supply the client application with consented user details. The scope and claim are defined when you configure the SaaS application or access application that supports OIDC in EAA.

  • Scope. References a set of claims. It identifies what information is requested to authenticate the user. The scope and claim are defined when you configure the SaaS application or access application in EAA. These scopes are available for OIDC:

    • profile (includes attributes or claims like name, nickname, family name)
    • email
    • address
    • phone
    • custom scope

  • Claim. A claim is a statement about the end-user and authentication event for the user. These are attributes that define the scope. For example, the profile scope contains claims such as name or nickname. You can configure a set of claims to identify the user in EAA identity provider that is delivered to the relying party.

  • Endpoints. The different endpoints or URI locations on the OP or RP that are used for OpenID protocol communication using REST methods are:

    • Discovery endpoint. OP endpoint that allows the client (SaaS application or access application) to discover OpenID features and other endpoints on the OP. This information is fixed at the location: https://<idp-hostname>/.well-known/openid-configuration, where is the hostname of OP. In this case, the OP is EAA or the ​Akamai​ identity provider.

    • Authorization endpoint. OP endpoint where the user is asked to authenticate and grant the client application consent to access their identity and any other required information such as email or address. This extra information is called user info claims. Once consent is given, this endpoint passes back an authorization code. This is the endpoint in which the user indirectly interacts with the identity provider through a user agent, for example a browser.

    • Token endpoint. OP endpoint where client application requests tokens and is authenticated. It also exchanges the authorization code from the authorization endpoint for an ID token, an access token, and optional refresh token. In EAA, the refresh token is for five minutes duration.

    • UserInfo endpoint. OP endpoint where client sends requests for identity claims. This is an OAuth 2.0 protected resource that is used by the identity provider to return consented user information or claims to the client application, provided that a valid access token is presented. No client ID or secret is required at this endpoint.

    • Redirect endpoint. RP endpoint that is pre-registered or configured in EAA. This is where the OP sends authentication responses.

    • JSON web key (JWK) endpoint. This is a common endpoint present in both the OP and the RP. The JSON web keys that are necessary to decrypt and validate the ID token are published.

Supported OpenID Connect specifications

The OpenID Connect specifications or standards that are supported are:

  • OpenID Connect Core. Authentication built upon OAuth 2.0 that uses attributes (claims) to gather information about the user. These authentication flows are supported as part of this core functionality:

    • Authorization Code Flow. In this flow, an authorization code is delivered at one of the redirect URI endpoints that you or an administrator configures for the client. This code is exchanged for an access token and an ID token at the token endpoint. All transactions between the client (SaaS application) and the OpenID provider use transport layer security (TLS). As a result, the OpenID provider authenticates the client with a client ID and secret before delivering tokens. These tokens are also never exposed to the agent (web browser). This authentication flow is considered the most secure.

    • Implicit Flow. In this flow, access tokens and ID tokens are returned to the client (SaaS application) without the OpenID provider authenticating the client (SaaS application). The redirect URI is used to confirm client identity.

  • OpenID Connect Discovery. Process for discovering endpoints on the OP through the discovery metadata URL.

  • OpenID Connect Session Management 1.0. Defines how to monitor a user's session and determines when the user is logged out. For example, if the user is logged out of OP, the user must also be logged out of the application (relying party).

  • OpenID Connect Front-Channel Logout 1.0. Sends logout requests through a user agent from the OpenID provider to the application (relying party).

  • Request for Comment (RFC) 7636. Uses Proof Key for Code Exchange (PKCE) to generate a random code value for each authentication transaction in case code values are intercepted.

Currently, these optional OpenID Connect specifications are not supported:
- Refresh Tokens
- private_key_jwt
- encryption
- offline access
- claims locales

OpenID Connect parameters for an application

You can add an application that uses the OpenID Connect protocol. The application can be a custom SaaS application or an access application in EAA. This process allows EAA to act as an OpenID provider that authenticates the user either to a SaaS application or an access application with application-facing mechanism set to OpenID Connect 1.0 standard.

When you configure such an application in EAA, a redirect URI is required from the application (relying party). The application sends and receives authentication responses to the redirect URI. In the application, this also may be called the redirect URL or the callback URL.

Parameters required for an application that supports OIDC:

  • Discovery URL. This URL is automatically generated based on the hostname of your identity provider. This page contains all the OpenID configuration endpoints and is formatted with this URL:https://<idp-hostname>/.well-known/openid-configuration, where <idp-hostname> is the hostname of the ​Akamai​ identity provider. You enter this URL in the application to allow the app to discover the endpoints of your configuration. If the application does not discover this URL automatically, you can download the metadata JSON file with the necessary endpoints and upload this file into the application. If an upload option is not available for this metadata, you must configure the application with the individual elements that are defined in the metadata JSON file.

  • Client ID. Unique ID generated for the application.

  • Client Secret. The secret that is used along with the client ID for authentication. In the authentication flow, two client secrets (the new and previous key) are available for use to support client secret rotation.

  • Claims. Defines the information that is required to identify and authenticate the user.

Field names or labels for an OpenID Connect configuration may vary in the application or relying party. You may need to modify the client metadata before you use it in the application.

Updated about 1 month ago