Custom claims in token introspection

[NicolasLiampotis]

Token introspection (https://tools.ietf.org/html/rfc7662) allows querying the authorization server for determining the active state of an OAuth 2.0 token and to determine meta-information about this token. We need to be able to control the claims that are returned in the token introspection response in addition to the standard claims (e.g. active, scope) defined in Section 2.2 of RFC7662.

[laskasn]

Currently, a sample response from the token introspection endpoint of keycloak is

{ "exp": 1621347927, "iat": 1621347867, "jti": "559a70fe-c157-4008-9c43-7dde960cf077", "iss": "http://localhost:8081/auth/realms/master", "aud": "account", "sub": "1541e579-a221-4a76-981b-768efcc25d05", "typ": "Bearer", "azp": "aaa", "session_state": "d539c307-462e-4dd8-89b5-eaec1baab244", "preferred_username": "nikolas", "email_verified": false, "acr": "1", "realm_access": { "roles": [ "default-roles-master", "offline_access", "uma_authorization" ] }, "resource_access": { "account": { "roles": [ "manage-account", "manage-account-links", "view-profile" ] } }, "scope": "email profile", "client_id": "aaa", "username": "nikolas", "active": true }

[laskasn]

So, it's actually an access token + the fields {client_id, username, active}

[laskasn]

all client mappers can modify this response. For instance, by adding a hardcoded claim mapper on the client, it adds the value into the introspection response.

[NicolasLiampotis]

Two points for discussion:

1. Investigate which clients have access to the introspection endpoint
2. If all confidential clients have access, investigate privacy/security issues and identify alternative client types who will not have access to introspection
3. Investigate how to add claims to the introspection endpoint response without including them in the access token

[cgeorgilakis]

Keycloak documentation for introspection : https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_token_introspection

[cgeorgilakis]

Two points for discussion:

1. Investigate which clients have access to the introspection endpoint
2. If all confidential clients have access, investigate privacy/security issues and identify alternative client types who will not have access to introspection
3. Investigate how to add claims to the introspection endpoint response without including them in the access token

Introspection rest api will fail if :

• Realm is disabled
• Public Client
• Client authedication failed due to Client misconfiguration. I could not understand details.
• False parameters (f.e. not provided token)
• Due to Client Policies in introspection request

I believe that the key for confidental client introspect restriction is appropriate Client Policies.

The three bullet can not be done. The only available parameter for introspection request is token_type_hint which value equal to requesting_party_token introspect RPT token ( default access token). I do not believe that we could do anything to affect scope with Client Mapper.