...

Validating the access token

...

Validating the access token (non-standard)

...

Keycloack provides a mechanism for validating

...

access token.

...

There are two ways to approach it - using Introspection Endpoint and validating tokens locally. See Keycloack documentation for more details. 

Using Introspection Endpoint

In order to manually validate a token issued by Keycloack, invoke Introspection Endpoint  /realms/{realm-name}/protocol/openid-connect/token/introspect

Please note that this endpoint can only be invoked by confidential clients (see OAuth 2 documentation for details).

To validate a token, make a

...

POST request with parameters sent as "application/x-www-form-urlencoded" data to the Introspection Endpoint (see above) with the following query parameters included:

introspection. Might take 2 possible values: access_token

...

include_permissions (optional):  Value can be "true" or "false" (default). Specifies whether the response should include information about the end user's Archie permissions within the scope of the access token.

detailed (optional):  Value can be "true" or "false" (default). Specifies whether the response should include the following information in the response: user_id, name (combined), first_name, last_name and email.

The response is a JSON object (MIME type "application/json") like this:

or refresh_token. 

The response is a JSON object (MIME type "application/json") like this:

{
    "active": true,
    "scope": "document",
    "client_id": "l238j323ds-23ij4

...

",

    "

...

user_name": "

...

jdoe",

    "

...

token_

...

type": "

...

bearer"

...

    "
...
exp": 1419356238,      
...
  
    "iat": 1419356238,    
    "
...
nbf": 
...
1419350238
}
Use person_id as a user's stable ID
Note that the user_name for a given user may change over time, e.g. if the user's email changes, and if the user account is closed it may be reused later by another account. If you need an immutable identifier that will not be reused, person_id is recommended.
Or, with both detailed=true and include_permissions=true:
{
    "user_name": "testuser",
    "scope": "person",
    "expires_in": "3192",
    "client_id": "my_account",
    "person_id": "11143",
    "user_id": "08573771072139469457090803092242",
    "name": "Test User",
    "first_name": "Test",
    "last_name": "User",
    "email": "test-user@cochrane.org",
    "permissions": [
        {
            "resource": "person",
            "entity": "D37BDF5182E26AA2013C72096D0CE6B1",
            "grants": ["view", "view_private", "write"]
        }
    ]
}
In case of an error condition the response will follow the same structure as for the token endpoint (see above).
Refreshing an access token
Refresh tokens can be used to obtain a new access token without asking for the end user's consent. Access tokens expire after 4 hours unless they are revoked. Refresh tokens are valid for 180 days or until they are used to obtain a new access token.
To refresh an access token (server-side flow only) the client's server makes a POST request to the token endpoint with the following parameters included ("application/x-www-form-urlencoded" format):
grant_type (required): Must be set to "refresh_token".
refresh_token (required): The previously obtained refresh token.
 
The format of the response is identical to the one returned when the original access token was obtained:
{
    "access_token": "71c9e4fba2f43815719b82132f3104ee71930031f50087049e3beb357d9a5107",
    "token_type": "Bearer",
    "expires_in": "14400",
    "refresh_token": "abad3cdea83b2e4d28594db35b526689da1e295fb34dcb13668723f1ecac14e7"
}
Note that a new refresh token is also issued with the response, so the old refresh token must be discarded by the client and replaced by the new token.
In case of an error condition, e.g. if the refresh token is no longer valid, the response will follow the same structure as for other token endpoint errors. The client should discard the refresh token and obtain a new access token using the server-side flow.
...
title
Should this be removed?
Revoking an access token (non standard)
An access token can be revoked/invalidated by making a GET or POST request to the token revoking endpoint (see above) with a single parameter:
access_token (required): The token to be revoked.
In case of an error condition the response will follow the same structure as for the token endpoint (see above).

Local validation
Due to the fact that Keycloack issued tokens are JWT digitally signed and encoded using JWS, access token can be locally validated using public keyof the issueing realm. The realm’s public key can be either hard coded in validation code, or the public key culd be looked-up and cached using the certificate endpoint with the Key ID (KID) embedded within the JWS.


Refreshing an access token
Refresh tokens can be used to obtain a new access token without asking for the end user's consent. Access tokens expire after 4 hours unless they are revoked. Refresh tokens are valid for 180 days or until they are used to obtain a new access token.
To refresh an access token (server-side flow only) the client's server makes a POST request to the token endpoint with the following parameters included ("application/x-www-form-urlencoded" format):
grant_type (required): Must be set to "refresh_token".
refresh_token (required): The previously obtained refresh token.
 
The format of the response is identical to the one returned when the original access token was obtained:
{
    "access_token": "71c9e4fba2f43815719b82132f3104ee71930031f50087049e3beb357d9a5107",
    "token_type": "Bearer",
    "expires_in": "14400",
    "refresh_token": "abad3cdea83b2e4d28594db35b526689da1e295fb34dcb13668723f1ecac14e7"
}
Note that a new refresh token is also issued with the response, so the old refresh token must be discarded by the client and replaced by the new token.
In case of an error condition, e.g. if the refresh token is no longer valid, the response will follow the same structure as for other token endpoint errors. The client should discard the refresh token and obtain a new access token using the server-side flow
...
.
Using an access token to access the API
...
If the call fails an HTTP error status code will be returned.
with parameters sent as
   "application/x-www-form-urlencoded" data