Refresh token with offline_access scope affected by session idle/session max
See original GitHub issueDescribe the bug
Hello there.
My keycloak configured with:
SSO Session Idle = 30m
SSO Session Max = 30m
And my refresh token with offline_access
scope has interesting lifetime:
- If the client inactive for more than 30m, then when I use the refresh token to fetch new access token keycloak’s response is:
{
"error": "invalid_grant",
"error_description": "Session doesn't have required client"
}
- If the client do at least one authentication request within 30m span then keycloack successfully provide me with new accept token and works fine until previous scenario happens.
According to the documentation refresh token with offline scope shouldn’t be affected by any of session idle/max.
Any ideas?
Version
14.0.0
Expected behavior
Keycloak provides access token
Actual behavior
{
"error": "invalid_grant",
"error_description": "Session doesn't have required client"
}
How to Reproduce?
Scnerio: Refresh token is not valid
- Login with scope
offline_access
- Wait for
session idle
timeout to pass - Make request to fetch new access token
Scnerio: Refresh token is valid
- Login with scope
offline_access
- Wait for time less than
session idle
timeout - Make request to fetch new access token
I’ve bash script to reproduce the behaviour. First scenarios requires sleep 2100s
and second something like sleep 1500s
#!/bin/bash
KC_SERVER=''
KC_REALM=''
KC_CLIENT=''
USERNAME=''
PASSWORD=''
KC_TOKEN_ENDPOINT=$KC_SERVER/auth/realms/$KC_REALM/protocol/openid-connect/token
echo "URL: $KC_TOKEN_ENDPOINT"
refresh_token=`curl -k \
-d "client_id=$KC_CLIENT" \
--data-urlencode "username=$USERNAME" \
-d "password=$PASSWORD" \
-d "grant_type=password" \
-d "scope=openid offline_access" \
$KC_TOKEN_ENDPOINT | jq -r '.refresh_token'`
echo $refresh_token
echo `date`
echo 'waiting ...'
sleep 2100s
curl -k \
-d "client_id=$KC_CLIENT" \
-d "grant_type=refresh_token" $KC_SERVER/auth/realms/$KC_REALM/protocol/openid-connect/token \
-d "refresh_token=$refresh_token" | jq
echo `date`
Anything else?
Refresh token from keycloak is correct one:
{
"iat": 1640106070,
"jti": "{id}",
"iss": "{my keycloack}",
"aud": "{my keycloack},
"sub": "{id},
"typ": "Offline",
"azp": "{my client}",
"session_state": "{id}",
"scope": "openid offline_access"
}
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
Refresh token (offline_access scope) affected by session idle ...
According to the documentation refresh token with offline scope shouldn't be affected by any of session idle/max. Any ideas?
Read more >Refresh Tokens - Auth0
Auth0 limits the amount of active refresh tokens to 200 tokens per user per application. This limit only applies to active tokens. If...
Read more >Offline Sessions and Offline tokens within Keycloak - JANUA
This article is dedicated to describe the behaviour and usage of offline sessions and offline tokens within Keycloak. The behaviour of offline tokens...
Read more >Refresh Tokens — IdentityServer4 1.0.0 documentation
Maximum lifetime of a refresh token in seconds. Defaults to 2592000 seconds / 30 days. Zero allows refresh tokens that, when used with...
Read more >Refresh access tokens - Okta Developer
This guide explains how to refresh access tokens with Okta. Learning outcomes. Understand how to set up refresh token rotation. Refresh access tokens....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@thomasrichner-oviva I think I see now. The issue here is that the flag
Offline Session Max Limited
is not taken into account when setting up the lifetime of client sessions. Once you enable it will continue to consider those related settings even though the flag is disabled.@yamsergey-oviva Try docker:
That is what I used to run both 16 and 14.