Gigya Job Openings

OpenID Connect Protocol Coverage

Skip to end of metadata
Go to start of metadata

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 ID Token (JWT) returned from OIDC flow.
  4. The id token (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.

  • No labels