OpenID Connect information
The Connectis Identity Broker supports the two most commonly used OpenID Connect flows: Authorisation Code and Implicit.
The Authorisation Code flow is used by clients to exchange an authorisation code for an Access Token. The Access Token can then be used at the Token endpoint to retrieve the JWT containing the required user information (claims).
See https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps for a detailed description of the flow.
Authorisation request:
<base_url>/broker/openidconnect/authorize?response_type=code&client_id=<client_id>&scope=openid&state=<state>&redirect_uri=<redirect_uri>
ID | Value | Description |
client_id | Unique Identifier | Identifies the client at the Connectis Identity Broker. This must be agreed upon between your service and Connectis before starting the integration. |
redirect_uri | Url | The url on your service that will receive the response. |
response_type | "Code" | This value must be set to "code" to retrieve an Authorisation Token. |
scope | openid | |
state | | An opaque value used by the client to prevent cross-site request forgery. |
nonce | Optional field | String value used to associate a client session with an ID Token, and to mitigate replay attacks. It is mandatory only for implicit flow. If sent, it will also be included in the JWT in the authorisation code flow. |
Authorisation response:
<redirect_uri>?code=<authorization_token>&state=<state>
Before the <authorization_token> is sent, the user must first authenticate himself/herself via an identity provider.
This endpoint can be used to retrieve an ID Token/Access Token, as well as to refresh an expired Access Token.
Token request (POST method):
<base_url>/broker/openidconnect/token?grant_type=<grant_type>&code=<code>&redirect_uri=<redirect_uri>&client_secret=<client_secret>
ID | Value | Description |
redirect_uri | Url | The url on your service that will receive the response. |
grant_type | "authorization_code"/”refresh_token” | To receive the ID Token, use "authorization_code". To refresh an expired Access Token, use "refresh token" |
client_secret | Unique identifier | A secret key agreed upon between your service and the Connectis Identity Broker. |
code | Unique identifier | This is the Authorisation Token returned by the Connectis Identity Broker from the authorisation endpoint. |
refresh_token | Unique identifier | This parameter is only mandatory when requesting a new Access Token. The value should match the value of the Refresh Token received from the Token endpoint when requesting the ID Token. |
client_id | Client identifier | |
Token response for grant_type = “authorization_code”(JSON format):
Content-Type: application/jsonCache-Control: no-storePragma: no-cache{"access_token":<access_token>,"token_type":"Bearer","expires_in":<expires_in>,"refresh_token":<refresh_token>,"id_token":<id_token>}
Id | Value | Description |
access_token | Unique identifier | The Access Token returned by the Connectis Identity Broker. |
token_type | "Bearer" | |
expires_in | integer | Defines the time (in milliseconds) when the Access Token will expire. |
id_token | JWT | Base64 encoded JSON containing information about the user. The JWT will be signed using the Connectis Identity Broker certificate. |
refresh_token | Unique identifier | The Refresh Token returned by the Connectis Identity Broker. |
Token response for grant_type = “refresh_token”(JSON format):
Content-Type: application/jsonCache-Control: no-storePragma: no-cache{"access_token": <access_token>,"token_type": "Bearer","refresh_token": <refresh_token>,"expires_in": <expires_in>}
This endpoint is used to retrieve claims about an authenticated user.
User info request (GET method):
<base_url>/broker/openidconnect/userinfoAuthorization: Bearer <access_token>
The request should contain the "Authorization" header with the following value: "Bearer" + empty space + <Access Token>.
User info response (JSON format):
{"sub": "248289761001","name": "Jane Doe","given_name": "Jane","family_name": "Doe","preferred_username": "j.doe","email": "janedoe@example.com","picture": "http://example.com/janedoe/me.jpg"}
This flow is suitable for client-side javascript applications that are unable to safely store a secret key.
The flow is much simpler, after the user authenticates himslef/herself via an identity provider, the application directly receives the tokens (with the required user information), without the need for additional endpoints invocation. See https://oauth.net/2/grant-types/implicit/ for a detailed description of the flow.
Authorisation request:
<base_url>/broker/openidconnect/authorize?response_type=id token token&client_id=<client_id>&scope=openid&state=<state>&redirect_uri=<redirect_uri>
ID | Value | Description |
client_id | Unique identifier | Identifies the client at the Connectis Identity Broker. This must be agreed upon between your service and Connectis before starting the integration. |
redirect_uri | Url | The url on your service that will receive the response. |
response_type | "id token token" | This value must be set to "id token token" in order to directly receive the ID Token. |
scope | openid | |
state | Optional field | An opaque value used by the client to prevent cross-site request forgery. |
nonce | Optional field | String value used to associate a client session with an ID Token, and to mitigate replay attacks. It is only mandatory for implicit flow. If sent, it will also be included in the JWT in the authorisation code flow. |
Authorization response:
<redirect_uri>?token_type=Bearer&id_token=<id_token>T&state=<state>
ID | Value | Description |
state | Unique identifier | The same value as sent in the request. |
token_type | “Bearer” | |
id_token | Base64 encoded string | The JWT containing user claims, signed by the Connectis Identity Broker. |