Back to Search Back to Search Results

OIDC Bearer Tokens

Portal requests may be authenticated by means of an OIDC Bearer token.

For portals that use OpenID Connect (OIDC) authentication, portal requests may use Bearer tokens to authenticate. The OIDC provider must support token generation and validation (and optionally, refreshing tokens). The process for configuring OIDC providers for token support will vary with the provider. Consult your OIDC provider administrative documentation for details and requirements. The OIDC client registration must support scopes "openid" and "offline_access", and conform to the OAuth2 "Authorization Code" flow. Titania Delivery only supports OIDC bearer tokens in JWT (JSON Web Token) format.

The OIDC security configuration must be set up in an organization accessible by the portal, and the portal must be configured to use the OIDC security configuration.

The process for using Bearer tokens is:

  1. A third-party application (or web page) authenticates itself with the OIDC provider.
  2. The client application obtains a bearer token from the OIDC provider.
  3. The client makes an HTTP request to a portal URL, and includes the bearer token. The bearer token may be attached to the request in one of these ways:
    • Put the bearer token in the Authorization request header, preceded by the the literal string "Bearer ". (This is the most secure, and preferred, method. See "Authorization Request Header Field" section in the "OAuth 2.0 Bearer Token Usage" RFC for additional details.)
    • In a POST request, add the bearer token as the value of a form url-encoded parameter named "access_token" in the body of the request. (This is less secure, and should be used only when the client application is unable to set request headers. See "Form-Encoded Body Parameter" section in the "OAuth 2.0 Bearer Token Usage" RFC for additional details.)
    • In a GET or POST request, add the bearer token as the value of a URL query parameter named "access_token".
      Note: This is considered a higher security risk than the other methods. By default, Titania Delivery does not support this method. Customers may request Oberon Technologies to enable this method for their site after acknowledging and accepting the security risks. (See "URI Query Parameter" section in the "OAuth 2.0 Bearer Token Usage" RFC for additional details.)
  4. Titania Delivery will validate the token using information from the OIDC provider. If the token is valid, the request will be processed normally. If the token has expired, the portal will attempt to obtain a fresh token, and, if successful, will return a 4xx HTTP response with the new token in the WWW-Authenticate response header. The client application may resubmit the request with the new token, or take other action. If the token cannot be validated, a 4xx HTTP response will be returned to the client.

The following industry standard specifications provide additional details about the processes and entities described here:

Parent topic: Portal Security