I’m using sample WindowsConsoleSystemBrowser and get the access token generated from keycloak.
Subsequently, I try to validate the token with curl at address <oidcServer>/token/introspect but the token is not valid.
How generate or validate this access code correctly?
I’m getting this information:
jti:1fdfa552-c745-41fe-ab98-c9cc18e84d14;
sub:17826477-591d-46bc-b5da-5731ad3e10a4;
typ:ID;
azp:smxxxpm;
sid:1ee4d385-4188-46dd-a65c-72504e47206f;
acr:1;
email_verified:False;
name:nomeSmit cognomeSmxx;
preferred_username:smxx;
given_name:nomeSmxx;
family_name:cognomeSmxx;
email:[email protected];
email_verified:false;
**AccessToken**:eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJUcWN1TUlTWEhSRGpReVBjT0pkc1g4WHpkNmNDVVBCQ052RndTOUstOXpJIn0.eyJleHAiOjE3MzQzNjE1NDUsImlhdCI6MTczNDM2MTI0NSwiYXV0aF90aW1lIjoxNzM0MzYxMjQ1LCJqdGkiOiJjYTkxYTViOC00NjkwLTQwNWEtOTRiOS04MDEyODcxMTViOTkiLCJpc3MiOiJodHRwczovL2dndWFpdGEtMjAxNS5vYmplY3R3YXkuaXQ6ODQ0My9yZWFsbXMvZ2d1YWl0YS0yMDE1IiwiYXVkIjoiYWNjb3VudCIsInN1YiI6IjE3ODI2NDc3LTU5MWQtNDZiYy1iNWRhLTU3MzFhZDNlMTBhNCIsInR5cCI6IkJlYXJlciIsImF6cCI6InNtaXRPcG0iLCJzaWQiOiIxZWU0ZDM4NS00MTg4LTQ2ZGQtYTY1Yy03MjUwNGU0NzIwNmYiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3QiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLWdndWFpdGEtMjAxNSJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoib3BlbmlkIGVtYWlsIHByb2ZpbGUiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsIm5hbWUiOiJub21lU21pdCBjb2dub21lU21pdCIsInByZWZlcnJlZF91c2VybmFtZSI6InNtaXQiLCJnaXZlbl9uYW1lIjoibm9tZVNtaXQiLCJmYW1pbHlfbmFtZSI6ImNvZ25vbWVTbWl0IiwiZW1haWwiOiJnaW9yZ2lvLmd1YWl0YUBvYmplY3R3YXkuaXQifQ.eeDnwjnfxP_vNgEK7W-ogE0r1qzDf_XA_LzDS5pQ-3sSGNN5YPTqv-rYk81g15q16NFQBzkopCGQ7ywRZpUfL7ov17YrDg3vwqdEjnL-h174XZstAAe25kYPzsEbREaDdHIaJYZzCQO88PwsrsgS6WccWMP7dRals9krZe0aNEnUHYtJ2EIWQUe2TRSOmpbcRW0f7fePbKCVQ9DTQ-_nYZJqAgTzpdwQyTbEV9tCeTf7FH3V9AlilnhdIg0-IEWgHDvUk36n2Q5ktQgsZB1bwWpwiMybQ4ynf7GI73cusXGXaQBaYPvwuQOX7khpJHC0w6ffB0LpmlrKXHvhBGeMOg;
**TypeToken**:Bearer;
RefreshToken:eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIxNGYzYjA5Ni04MzI4LTQxOTQtOTJmNy0xMzA3ODE0MDQxMzYifQ.eyJleHAiOjE3MzQzNjMwNDUsImlhdCI6MTczNDM2MTI0NSwianRpIjoiM2E5M2Q5MDktMDcwNS00YzJhLThiYTItMWJhMDY4NDQ4NTc2IiwiaXNzIjoiaHR0cHM6Ly9nZ3VhaXRhLTIwMTUub2JqZWN0d2F5Lml0Ojg0NDMvcmVhbG1zL2dndWFpdGEtMjAxNSIsImF1ZCI6Imh0dHBzOi8vZ2d1YWl0YS0yMDE1Lm9iamVjdHdheS5pdDo4NDQzL3JlYWxtcy9nZ3VhaXRhLTIwMTUiLCJzdWIiOiIxNzgyNjQ3Ny01OTFkLTQ2YmMtYjVkYS01NzMxYWQzZTEwYTQiLCJ0eXAiOiJSZWZyZXNoIiwiYXpwIjoic21pdE9wbSIsInNpZCI6IjFlZTRkMzg1LTQxODgtNDZkZC1hNjVjLTcyNTA0ZTQ3MjA2ZiIsInNjb3BlIjoib3BlbmlkIGJhc2ljIHJvbGVzIHdlYi1vcmlnaW5zIGVtYWlsIHByb2ZpbGUgYWNyIn0.1aQy6Q18cICSXCPTIACaNTsjPligEHepoEQco0z_j0LHQVVDkZ-aU0GrqcABdEMyU-OH97sswhwUuJb7ZqK5lw;
And use this curl command:
curl -s --insecure -X "POST" "<oidcServer>/token/introspect" ^
-H "accept: application/json" ^
-H 'Content-Type: application/x-www-form-urlencoded' ^
-d "client_id=smxxxpm" ^
-d "client_secret=<oidcClientSecret>" ^
-d "token=<AccessToken>"
Result is:
{
"active": false
}
If generate token with curl and validate access token with previous curl i’ts ok:
curl -s --insecure -X "POST" "<oidcServer>/token" ^
-H "accept: application/json" ^
-H 'Content-Type: application/x-www-form-urlencoded' ^
-d "username=<username>" ^
-d "password=<password>" ^
-d "grant_type=password" ^
-d "client_id=smxxxpm" ^
-d "client_secret=<oidcClientSecret>"
Result is:
{
"exp": 1734362264,
"iat": 1734361964,
"jti": "ab514bb3-17e3-46b6-8da0-46ef03adf5a8",
"iss": "<odicServer>+realms",
"aud": "account",
"sub": "17826477-591d-46bc-b5da-5731ad3e10a4",
"typ": "Bearer",
"azp": "smxxxpm",
"sid": "0640bef6-7b49-4af0-bf8d-ab05745558ab",
"acr": "1",
"allowed-origins": [
"http://localhost"
],
"realm_access": {
"roles": [
"offline_access",
"uma_authorization",
"default-roles-xxxxxx-xxxx"
]
},
"resource_access": {
"account": {
"roles": [
"manage-account",
"manage-account-links",
"view-profile"
]
}
},
"scope": "email profile",
"email_verified": false,
"name": "nomeSmxx cognomeSmxx",
"preferred_username": "smxx",
"given_name": "nomeSmxx",
"family_name": "cognomeSmxx",
"email": "[email protected]",
"client_id": "smxxxpm",
"username": "smxx",
"token_type": "Bearer",
"active": true
}
gguaita is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You typically don’t use the client_id/secret when using the token introspection endpoint, instead you provide the API’s (protected resource) identity, and in the form of a basic authorization header.
Also, the token introspection is meant for the APIs to use, not the client application.
like this
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=mF_9.B5f-4.1JqM&token_type_hint=access_token
See the documentation: OAuth 2.0 Token Introspection
it says
In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients.
This means that the client does not need to know anything about the
content or structure of the token itself, if there is any. However,
there is still a large amount of metadata that may be attached to a
token, such as its current validity, approved scopes, and information
about the context in which the token was issued. These pieces of
information are often vital to protected resources making
authorization decisions based on the tokens being presented.
1
I figured out where the problem lay with Keycloack’s technicians.
keycloak token introspection always fails with {“active”:false}
You need to make sure that you introspect the token using the same DNS hostname/port as the request. Unfortunately that’s a not widely documented “feature” of Keycloak…
Thank you for your attention
gguaita is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.