[keycloak-user] OAuth2 token introspection requires an active session?

Marek Posolda mposolda at redhat.com
Mon May 15 09:37:11 EDT 2017


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/e4aba9e4713c0b7b6084b9c639ee6ddccc82964e
>
> 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 at redhat.com
>>> <mailto:mposolda at 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/test.sh
>>>      <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
>>>      <https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/offline.html>
>>>      >>>
>>>      >>>
>>>      >>> Thanks for your support.
>>>      >>>
>>>
>>>      _______________________________________________
>>>      keycloak-user mailing list
>>>      keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>      https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>      <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>
>>>



More information about the keycloak-user mailing list