This looks like a bug. Could you please create JIRA with the info you mentioned here? Please also link your new JIRA with https://issues.jboss.org/browse/KEYCLOAK-4521, which is quite similar issue. Marek On 28/04/17 09:51, Iván Perdomo wrote: > Hi all, > > We're trying to use offline access [1] to retrieve access_tokens on > behalf of the user and access a protected resource in a long running > process. > > This protected resource checks the validity of the access_token using > the OAuth2 token introspection. > > In our tests we found that the introspection flag "active" true|false > depends on having an active session in the server. Which seems to defeat > the purpose of the offline access capabilities. > > I have tested with versions 2.5.5.Final and 3.0.0.Final and the behavior > is the same. > > * Get an offline token via direct grants > * Get an access_token using the offline_token > * We have an active session > * Use the token introspection for the access_token and get the expected > result: active=true > * Wait for SSO Idle timeout (so the session expires) > * Get a new access_token using the "stored" offline_token > * Use the token introspection with the new access_token. Keycloak > returns active=false because we don't have a session. But the > access_token is valid, and not expired. > > The following code repository has an isolated test case of this scenario: > > https://github.com/iperdomo/keycloak-oauth2-instrospection > > The described steps are in this script: > > https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/te... > > > I tried to look for logged issues regarding token introspection and > didn't found anything related to this problem. > > Is this a bug or an expected behavior? > > [1] > https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/o... > > > Thanks for your support. >

Yes. I've just changed link kind "Caused by" to "related to" . Thanks! Marek On 02/05/17 13:33, Iván Perdomo wrote: > Hi Marek, > > I created the issue and link it to the one you mentioned (not completely > sure if the link is correct). > > https://issues.jboss.org/browse/KEYCLOAK-4829 > > Thanks, > > On 05/02/2017 12:34 PM, Marek Posolda wrote: >> This looks like a bug. Could you please create JIRA with the info you >> mentioned here? Please also link your new JIRA with >> https://issues.jboss.org/browse/KEYCLOAK-4521, which is quite similar >> issue. >> >> Marek >> >> On 28/04/17 09:51, Iván Perdomo wrote: >>> Hi all, >>> >>> We're trying to use offline access [1] to retrieve access_tokens on >>> behalf of the user and access a protected resource in a long running >>> process. >>> >>> This protected resource checks the validity of the access_token using >>> the OAuth2 token introspection. >>> >>> In our tests we found that the introspection flag "active" true|false >>> depends on having an active session in the server. Which seems to defeat >>> the purpose of the offline access capabilities. >>> >>> I have tested with versions 2.5.5.Final and 3.0.0.Final and the behavior >>> is the same. >>> >>> * Get an offline token via direct grants >>> * Get an access_token using the offline_token >>> * We have an active session >>> * Use the token introspection for the access_token and get the expected >>> result: active=true >>> * Wait for SSO Idle timeout (so the session expires) >>> * Get a new access_token using the "stored" offline_token >>> * Use the token introspection with the new access_token. Keycloak >>> returns active=false because we don't have a session. But the >>> access_token is valid, and not expired. >>> >>> The following code repository has an isolated test case of this scenario: >>> >>> https://github.com/iperdomo/keycloak-oauth2-instrospection >>> >>> The described steps are in this script: >>> >>> https://github.com/iperdomo/keycloak-oauth2- instrospection/blob/master/test.sh >>> >>> >>> I tried to look for logged issues regarding token introspection and >>> didn't found anything related to this problem. >>> >>> Is this a bug or an expected behavior? >>> >>> [1] >>> https://keycloak.gitbooks.io/documentation/server_admin/ topics/sessions/offline.html >>> >>> >>> Thanks for your support. >>> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Yes, there is active session for offline tokens after startup. But both introspection and userInfo endpoint doesn't lookup for offline sessions ATM, but just for "online" sessions from the "sessions" cache. Hence once they receive the token, which was created through the refresh of offline token, they won't find the session and reply the "400 Bad request" error. Marek On 03/05/17 15:47, Stian Thorgersen wrote: > Marek - isn't the offline session recovered at startup so there will > be an active session for offline tokens as well right? > > On 2 May 2017 at 14:23, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > Yes. I've just changed link kind "Caused by" to "related to" . > > Thanks! > Marek > > On 02/05/17 13:33, Iván Perdomo wrote: > > Hi Marek, > > > > I created the issue and link it to the one you mentioned (not > completely > > sure if the link is correct). > > > > https://issues.jboss.org/browse/KEYCLOAK-4829 > <https://issues.jboss.org/browse/KEYCLOAK-4829> > > > > Thanks, > > > > On 05/02/2017 12:34 PM, Marek Posolda wrote: > >> This looks like a bug. Could you please create JIRA with the > info you > >> mentioned here? Please also link your new JIRA with > >> https://issues.jboss.org/browse/KEYCLOAK-4521 > <https://issues.jboss.org/browse/KEYCLOAK-4521>;, which is quite > similar > >> issue. > >> > >> Marek > >> > >> On 28/04/17 09:51, Iván Perdomo wrote: > >>> Hi all, > >>> > >>> We're trying to use offline access [1] to retrieve > access_tokens on > >>> behalf of the user and access a protected resource in a long > running > >>> process. > >>> > >>> This protected resource checks the validity of the > access_token using > >>> the OAuth2 token introspection. > >>> > >>> In our tests we found that the introspection flag "active" > true|false > >>> depends on having an active session in the server. Which seems > to defeat > >>> the purpose of the offline access capabilities. > >>> > >>> I have tested with versions 2.5.5.Final and 3.0.0.Final and > the behavior > >>> is the same. > >>> > >>> * Get an offline token via direct grants > >>> * Get an access_token using the offline_token > >>> * We have an active session > >>> * Use the token introspection for the access_token and get the > expected > >>> result: active=true > >>> * Wait for SSO Idle timeout (so the session expires) > >>> * Get a new access_token using the "stored" offline_token > >>> * Use the token introspection with the new access_token. Keycloak > >>> returns active=false because we don't have a session. But the > >>> access_token is valid, and not expired. > >>> > >>> The following code repository has an isolated test case of > this scenario: > >>> > >>> https://github.com/iperdomo/keycloak-oauth2-instrospection > <https://github.com/iperdomo/keycloak-oauth2-instrospection> > >>> > >>> The described steps are in this script: > >>> > >>> > https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/te... > <https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/te... > >>> > >>> > >>> I tried to look for logged issues regarding token > introspection and > >>> didn't found anything related to this problem. > >>> > >>> Is this a bug or an expected behavior? > >>> > >>> [1] > >>> > https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/o... > <https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/o... > >>> > >>> > >>> Thanks for your support. > >>> > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > <https://lists.jboss.org/mailman/listinfo/keycloak-user> > >

Hi, Yes, I think that it is just for the customer related issues. The details can be clarified by RH support or maybe someone else from the team though... Ivan, I don't know if you (or your company) are customer or if it's coincidence that someone else, who is customer, requested this issue :) Anyway, it's here because it was customer requirement. Marek On 12/05/17 09:52, Iván Perdomo wrote: > Hi, > > First of all, thanks for fixing this issue. A change landed in `master` > branch. > > https://github.com/keycloak/keycloak/commit/e4aba9e4713c0b7b6084b9c639ee6... > > I'm aware that Keycloak offers a 'best effort' community based support, > but I would like to know/understand the rule for backporting changes to > 2.5.x branch. Are this just for RH-SSO reported issues? > > Thanks, > > On 05/03/2017 09:32 PM, Marek Posolda wrote: >> Yes, there is active session for offline tokens after startup. But both >> introspection and userInfo endpoint doesn't lookup for offline sessions >> ATM, but just for "online" sessions from the "sessions" cache. Hence >> once they receive the token, which was created through the refresh of >> offline token, they won't find the session and reply the "400 Bad >> request" error. >> >> Marek >> >> On 03/05/17 15:47, Stian Thorgersen wrote: >>> Marek - isn't the offline session recovered at startup so there will >>> be an active session for offline tokens as well right? >>> >>> On 2 May 2017 at 14:23, Marek Posolda <mposolda(a)redhat.com >>> <mailto:mposolda@redhat.com>> wrote: >>> >>> Yes. I've just changed link kind "Caused by" to "related to" . >>> >>> Thanks! >>> Marek >>> >>> On 02/05/17 13:33, Iván Perdomo wrote: >>> > Hi Marek, >>> > >>> > I created the issue and link it to the one you mentioned (not >>> completely >>> > sure if the link is correct). >>> > >>> > https://issues.jboss.org/browse/KEYCLOAK-4829 >>> <https://issues.jboss.org/browse/KEYCLOAK-4829> >>> > >>> > Thanks, >>> > >>> > On 05/02/2017 12:34 PM, Marek Posolda wrote: >>> >> This looks like a bug. Could you please create JIRA with the >>> info you >>> >> mentioned here? Please also link your new JIRA with >>> >> https://issues.jboss.org/browse/KEYCLOAK-4521 >>> <https://issues.jboss.org/browse/KEYCLOAK-4521>;, which is quite >>> similar >>> >> issue. >>> >> >>> >> Marek >>> >> >>> >> On 28/04/17 09:51, Iván Perdomo wrote: >>> >>> Hi all, >>> >>> >>> >>> We're trying to use offline access [1] to retrieve >>> access_tokens on >>> >>> behalf of the user and access a protected resource in a long >>> running >>> >>> process. >>> >>> >>> >>> This protected resource checks the validity of the >>> access_token using >>> >>> the OAuth2 token introspection. >>> >>> >>> >>> In our tests we found that the introspection flag "active" >>> true|false >>> >>> depends on having an active session in the server. Which seems >>> to defeat >>> >>> the purpose of the offline access capabilities. >>> >>> >>> >>> I have tested with versions 2.5.5.Final and 3.0.0.Final and >>> the behavior >>> >>> is the same. >>> >>> >>> >>> * Get an offline token via direct grants >>> >>> * Get an access_token using the offline_token >>> >>> * We have an active session >>> >>> * Use the token introspection for the access_token and get the >>> expected >>> >>> result: active=true >>> >>> * Wait for SSO Idle timeout (so the session expires) >>> >>> * Get a new access_token using the "stored" offline_token >>> >>> * Use the token introspection with the new access_token. Keycloak >>> >>> returns active=false because we don't have a session. But the >>> >>> access_token is valid, and not expired. >>> >>> >>> >>> The following code repository has an isolated test case of >>> this scenario: >>> >>> >>> >>> https://github.com/iperdomo/keycloak-oauth2-instrospection >>> <https://github.com/iperdomo/keycloak-oauth2-instrospection> >>> >>> >>> >>> The described steps are in this script: >>> >>> >>> >>> >>> https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/te... >>> <https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/te... >>> >>> >>> >>> >>> >>> I tried to look for logged issues regarding token >>> introspection and >>> >>> didn't found anything related to this problem. >>> >>> >>> >>> Is this a bug or an expected behavior? >>> >>> >>> >>> [1] >>> >>> >>> https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/o... >>> <https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/o... >>> >>> >>> >>> >>> >>> Thanks for your support. >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> <https://lists.jboss.org/mailman/listinfo/keycloak-user> >>> >>> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user