Repository navigation
'Key not found' error for a GET request to userinfo endpoint, with a valid access token #48956
|
Repeating what's in my SO question here: For a local dev environment, I have keycloak (v 26.4.7) running in docker-compose. I've configured a realm with a client, configured for OIDC. I can successfully generate a valid access token via keycloak-js, and I can validate and parse that token in both my UI and backend. Manually checking the header, I can see that the However, when I then attempt (manually via cURL, for now) to access the
I'm confused about how Keycloak can be not finding the key that it's just signed the token with. In the UI, I can see that the From a quick search of the keycloak source code, there are only a handful of places where that specific error message would be thrown, all of which look to be immediately after it's tried to look up the key, and got a I'm sure I'm making a rookie error, but not sure where to look. Any suggestions for anything else I should be checking? Or suggested solutions? |
Replies: 1 comment 1 reply
|
"Key not found" on the userinfo endpoint usually means Keycloak is trying to verify the access token's signature with a key that doesn't exist in the realm's active key set anymore. The most common cause in a docker-compose setup: your Keycloak container got recreated (or the DB volume got wiped), which regenerated the realm keys. But you're still holding an access token signed with the old key. The Quick check: decode your access token (jwt.io or If they DO match, another possibility is that you have multiple realm keys and the signing key is different from the one being looked up. Go to Realm Settings → Keys → check which key is marked as "Active" for Also worth checking: are you hitting the userinfo endpoint on the same Keycloak instance that issued the token? In docker-compose with multiple replicas or a reverse proxy, requests could land on a different instance with different keys if you don't have a shared DB. |
"Key not found" on the userinfo endpoint usually means Keycloak is trying to verify the access token's signature with a key that doesn't exist in the realm's active key set anymore.
The most common cause in a docker-compose setup: your Keycloak container got recreated (or the DB volume got wiped), which regenerated the realm keys. But you're still holding an access token signed with the old key. The
kidin the token header might match what you see in the admin UI because you're looking at the new keys — but the token was signed by the previous instance's key.Quick check: decode your access token (jwt.io or
jq -R 'split(".") | .[0],.[1] | @base64d | fromjson') and compare thekidin the h…