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 email@example.com.
OpenID Connect is a protocol for authenticating users, built on top of the OAuth 2.0 authorization framework. Using Gigya, you can act as an OpenID Connect Provider (OP), authenticating users using the OpenID Connect (OIDC) protocol, or as a relying party (RP) that requests user authorization from an OP.
OpenID Connect uses the following terminology:
- Claim: Information asserted about a user, such as a first name or phone number.
- 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.
- ID Token: A JSON Web Token (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
Supported Endpoint Parameters
Gigya supports the following parameters when connecting to an OP endpoint:
|access_token||The access_token received from the Authorization endpoint for the specific user.|
|client_id||The clientID the OP received when creating this RP. This can also be returned using the getRP API.|
|clientSecret||The 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.|
|code||The code received from the Authorization endpoint, if requested.|
Whether the user agreed to consent or not.
A string value that defines how the Authorization endpoint displays the authentication and consent user interfaces to the user.
Defines what type of request is being presented in exchange for the access token.
|jwt||The signed consent when the mode is set to afterConsent.|
A Gigya defined indication for the flow in which a Proxy page is called.
|nonce||A unique string that associates the current Client session with an ID Token.|
Defines whether the Authorization endpoint prompts the user for re-authentication and/or consent.
|redirect_uri||Defines the URI which the response will be sent to. This URI must have been previously defined during RP creation.|
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:
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.
|userKey||A Gigya user/application key that is required to be passed to the consent endpoint when constructing the consent object signature using an application or user secret.|
Note that Gigya does not currently support the following features of the OIDC protocol:
- request - The request authorization request parameter.
- Self-issued OpenID Providers.
- Aggregated and distributed claims.
- Client authentication.
Refresh Token Example Flow
- User authenticates using OIDC code flow and code is returned from authorize endpoint.
- code is sent to token endpoint and access_token is returned and refresh_token.
- access_token sent to userinfo endpoint to receive ID Token (JWT) returned from OIDC flow.
- The id token (userinfo) is returned.
- The access_token expires.
- The clients application server calls the token endpoint with the previously received refresh_token and client_id/clientSecret.
- New access_token is returned with refresh_token.
Example Code For Exchanging a refresh_token For A New access_token
Whenever a new access_token is returned, all previously valid access tokens for that sub are revoked and no longer valid.
Valid Response Example
Invalid Response Example
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.
Code Flow Diagram With Gigya as Openid Connect Provider