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_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