Versions Compared

Old Version 15

changes.mady.by.user Vytautas Butkevicius

Saved on

compared with

New Version 16

changes.mady.by.user Sandra Aleksieje

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For any call to the token endpoint, including this, the client must provide its credentials as Basic HTTP authentication with client ID as user name and client secret as password. The authentication must be provided in the Authorization header for a confidential client.

Note
titleCheck if valid
Note: the specification allows, but discourages, providing the information as parameters in the request body instead (client_id and client_secret), but Keycloak does not allow this for confidential clients. And since a public client is not expected to use this endpoint and this flow, this is not relevant for practical purposes.

Before building the header for Basic authentication, client IDs and client secrets containing special characters including %, +, and all non-ASCII characters  must be encoded using the UTF-8 character encoding scheme first; the resulting octet sequence then needs to be further application/x-www-form-urlencoded (see section 2.3.1 of the specification). To build the header, the encoded credentials are separated by a colon, the resulting string is base 64 encoded, and the result is prefixed with "Basic ".

...

The client-side flow is optimised for public clients such as pure HTML5/JavaScript clients.

...

titleCheck if valid

...

.

The client directs the end user's browser (e.g. in a pop-up window or IFRAME) to the authorization endpoint with the following query parameters added ("application/x-www-form-urlencoded" format) to the endpoint URI:

...

For further details see section 5.2 of the specification.

https://www.keycloak.org/docs/latest/securing_apps/index.html#validating-access-tokens

Note
titleShould this be removed?

Validating the access token (non-standard)

Archie provides a mechanism for validating and obtaining information about an access token. If the OAuth 2.0 authorization framework is used for single sign on only by a public client it is important to validate the token to ensure that the request to the redirect URI is genuine. 

To validate a token, make a GET or POST request to the token information endpoint (see above) with the following query parameters included:

access_token (required): The token to be validated. This can also be provided in the Authorization header in the form: Bearer [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:

{
    "user_name": "testuser",
    "scope": "document",
    "expires_in": "2410",
    "client_id": "my_account",
    "person_id": "11143"
}

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

...