SAP Customer Data Cloud Positions

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



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.
  • 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.
  • 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

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: 


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.

Whether the user agreed to consent or not.

Supported values:

  • true
  • false

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.

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.

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.

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.

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

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.

userKeyA 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.

Unsupported Features

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



Refresh Token Example Flow

  1. User authenticates using OIDC code flow and code is returned from authorize endpoint.
  2. code is sent to token endpoint and access_token is returned and refresh_token.
  3. access_token sent to userinfo endpoint to receive userInfo data (JSON) returned from OIDC flow.
  4. The userinfo is returned.
  5. The access_token expires.
  6. The clients application server calls the token endpoint with the previously received refresh_token and client_id/clientSecret.
  7. 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.

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
$clientID = "<The RP client_id>";
$clientSecret = "<The RP client_secret>";
$apiKey = "<The OP API key>";
$errors = "";

if (isset($_POST['refreshToken']) && $_POST['refreshToken'] !== "") {
    $refreshToken = $_POST['refreshToken'];
} else {
    $refreshToken = null;
    $errors .='refreshToken was undefined. ';

// Try to refresh
function tryRefresh($inc_token,$id,$sec,$api) {
    $authHeader="Basic ";
    $client_ID = $id;
    $secret= $sec;
    $hashedAuthString=base64_encode($client_ID . ":" . $secret);
    $authHeader .= $hashedAuthString;

    $fields = array(
    foreach($fields as $key=>$value)
        $postvars.= $sep.urlencode($key).'='.urlencode($value);

    $ch = curl_init();
    $urlrefresh = "" . $api . "/token";
    curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: ' . $authHeader));
    $curlResultRefresh = curl_exec($ch);
    echo '"response":' . $curlResultRefresh;
if ($refreshToken) {
} else {
    echo '"response":{ "error" : "invalid or missing required parameter", "message" : "' . $errors . '" }';


Valid Response Example

  "access_token": "st2.zzzzzzzzzzzzzzzzzzzzzzzzzzz.XXXXXXXXXXXXXXXXXXXXXX.yyyyyyyyyyyyyyyyyyyyyyyyyyy",
  "token_type": "Bearer",
  "expires_in": 315360000,
  "refresh_token": "st2.ututuututututuututututututu.xxxxxxxxxxxxxxxxxxxxxx.-zzzzzzzzzzzzzzZZZZzzzzzzzz"

Invalid Response Example

"response":{"error":"invalid_grant","error_description":"The provided authorization code or refresh token is invalid."}


Unable to render {include} The included page could not be found.

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




Additional Information

OpenID Connect Provider Setup

OpenID Connect REST APIs

Customizing Login for Multiple RPs