OpenID Connect

Skip to end of metadata
Go to start of metadata

The Gigya OpenID Connect service is part of our Federated Identity Management Services, which are premium services that require separate activation. If it is not yet a part of your existing site package, please contact support by submitting a ticket through your Console Support Portal or sending an email to support@gigya.com.

 

Overview

OpenID Connect is a protocol for authenticating users, built on top of the OAuth 2.0 authorization framework.Using Gigya, you can act as OpenID Connect Providers (OP), authenticating users using the OpenID Connect (OIDC) protocol, or as a relying party (RP) that requests user authorization from an OP.

Terminology

OpenID Connect uses the following terminology:

  • Claim: Information asserted about a user, such as a first name or phone number.
  • Endpoint: 
    • Authorization Endpoint: Performs authentication of the user using request parameters defined by OAuth 2.0 and additional parameters and parameter values defined by OpenID Connect. Returns an authorization code. This code should be sent to the token endpoint to receive an id_token and/or access_token.
    • Token Endpoint: Issues an access_token, id_token and refresh_token to the RP. 
    • Introspection Endpoint: Used for determining the status of a current access_token (valid or invalid). If the token is valid, it also returns details about the token such as its type, the client_id of the entity that it was issued to, expiration, etc. If the token is invalid, it returns "false", and no additional information. 
  • Flow: OpenID provides three separate options for flows for authenticating users: Authorization Code, Implicit, and Hybrid. For more information, see OpenID Provider Setup and the OpenID specification.
  • OpenID Connect Provider (OP): An identity provider that is capable of authenticating an end user and providing claims to a Relying Party. Activating your account as an OP will enable 3rd party sites (relying parties, or RPs) to authenticate their users against your existing user base. For information on setting up your OP configuration, see OpenID Provider Setup.
  • Relying Party (RP): An OAuth 2.0 client application requiring end user authentication and claims from an OpenID Provider (OP). For information on setting up your RP configuration, see OpenID Connect RP Setup
  • Scope: The type of data to which RPs are granted access. For more information, see allowedScopes.
  • Tokens: The JSON Web Token (JWT) returned by any of the endpoints. 
    • ID Token: A JWT signed by the OP that contains identity information about the user being authenticated, as well as information about the token itself, such as the time it was issued and its expiration time.
    • Access Token: Used to grant or deny access to resources (authorization rather than authentication).
    • Refresh Token: Used to generate a new access token. 
    • Code: Used in the code flow to issue an access token. 

To configure the service via API, see FIdM OIDC OP REST.

High-level Gigya OIDC Overview

OpenID Connect Protocol Coverage

The table below lists all query string parameters currently supported by Gigya's OP endpoints.

Supported Endpoint Parameters

Gigya supports the following parameters when connecting to an OP endpoint: 

 

NameDescription
access_tokenThe access_token received from the Authorization endpoint for the specific user.
client_idThe clientID the OP received when creating this RP. This can also be returned using the getRP API.
clientSecretThe secret the OP received when creating this RP and is required when using server-to-server calls to the Token endpoint when the RP is using Authorization Code Flow.
codeThe code received from the Authorization endpoint, if requested.
consent

Whether the user agreed to consent or not.

Supported values:

  • true
  • false
display

A string value that defines how the Authorization endpoint displays the authentication and consent user interfaces to the user.

Supported values:

  • page - (default) - Displayed within a full user-agent page view.
  • popup - Displayed within a popup user-agent window.
  • touch - Displayed specifically with a touch (device) interface.
  • wap - Displayed specifically with a 'feature phone' interface.
grant_type

Defines what type of request is being presented in exchange for the access token.

Supported values:

  • authorization_code
  • refresh_token
    • Refresh tokens can only be issued via the Token endpoint in a code authentication flow. Refresh tokens are always generated via the code flow and do not currently require any additional scopes. Refresh tokens are valid for the lifetime of the user's originating session.
jwtThe signed consent when the mode is set to afterConsent.
mode

A Gigya defined indication for the flow in which a Proxy page is called.

Supported values:

  • login
  • error
  • afterLogin
  • afterConsent
nonceA unique string that associates the current Client session with an ID Token.
prompt

Defines whether the Authorization endpoint prompts the user for re-authentication and/or consent.

Supported values:

  • none - The server must not display any user interface pages.
  • login - (default) - The server will prompt the user for re-authentication.
  • consent - The server will prompt the user for consent before returning any information to the RP.
  • select_account - The server will prompt the user to select an account, if they have multiple accounts on the OP.

redirect_uriDefines the URI which the response will be sent to. This URI must have been previously defined during RP creation.
response_type

The response_type the RP wishes to receive from the OP. The requested response_type must be of a valid response_type (or multiple types) as defined by the OP during RP creation.

supportedResponseTypes are defined by the OP and can be any combination of:

  • code
  • id_token
  • id_token token
  • code id_token
  • code token
  • code id_token token
scope

The scopes being requested by the RP. Must include openid and may also include either email and/or profile. The requested scopes must have been previously defined during RP creation to be valid. This is a space delimited string.

Depending upon the position in the authorization flow, scope may be the scopes that were consented to by the end-user, which may be more restrictive than those requested by the RP.

Unsupported Features

Note that Gigya does not currently support the following features of the OIDC protocol:

 

Detailed Gigya Flow 

This is the flow of the User Authentication stage requiring Login.

  • 1.    The RP generates the request and sends it to the Authorization endpoint.
  • 2.    The Authorize endpoint redirects to the OP's Proxy page.
  • 3.    The Proxy page checks if the user is logged-in.
  • 4.    If not logged in, user is prompted to login, then proceeds to the next step.
  • 5.    If logged in, proceeds to next step.
  • 6.    The Proxy page redirects to the consentURL (Partner Endpoint).
  • 7.    If consent is required, the user provides consent. The endpoint then validates the authorization.
  • 8.    The consentURL (partner endpoint) redirects back to the Proxy page with the requested information (token/code).
  • 9.    The Proxy page validates the token.
  • 10.  The Proxy page redirects to the Authorize endpoint.
  • 11.  The Authorize endpoint redirects back to the RP.

 

 

Additional Information

OpenID Connect Provider Setup

OpenID Connect REST APIs