[keycloak-dev] Identity Brokering token storage and retrieval

[Bill Burke]

On 4/23/2015 10:12 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 23 April, 2015 3:07:21 PM
>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>>
>>
>> On 4/23/2015 6:40 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>> <keycloak-dev at lists.jboss.org>, "Bill Burke"
>>>> <bburke at redhat.com>
>>>> Sent: Thursday, 23 April, 2015 11:31:25 AM
>>>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>>>
>>>> On 23.4.2015 07:52, Stian Thorgersen wrote:
>>>>> Any comments on this?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>>>>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>>>>>
>>>>>> We've already discussed this, but didn't come to a conclusion.
>>>>>>
>>>>>> There's two separate use-cases to consider:
>>>>>>
>>>>>> 1. Authentication
>>>>>> 2. Offline access
>>>>>>
>>>>>> For simplicity the examples below assumes OpenID Connect, but same logic
>>>>>> applies to SAML.
>>>>>>
>>>>>>
>>>>>> Authentication
>>>>>> --------------
>>>>>> In this case user authenticates using an external IdP. After the user
>>>>>> has
>>>>>> authenticated the access and refresh (if available) tokens are stored in
>>>>>> user session. Tokens are automatically refreshed by Keycloak to support
>>>>>> brokered log out. In this case an application can only retrieve an
>>>>>> access
>>>>>> token for the identity provider that was used to authenticate the user.
>>>>>>
>>>>>>
>>>>>> Offline access
>>>>>> --------------
>>>>>> In this case we should add the option "offline access" to the provider
>>>>>> config. When enabled we add "offline" to the requested scope. When a
>>>>>> user
>>>>>> first logs in or links through account mngmt we store the refresh token
>>>>>> (aka
>>>>>> "offline token") in the user store. As this is a long term token I don't
>>>>>> see
>>>>>> any problems using the user store for it. In this case an application
>>>>>> can
>>>>>> retrieve an access token for the identity provider that was used to
>>>>>> authenticate the user, but also for an identity providers what have
>>>>>> "offline
>>>>>> access" enabled and there's an token store in the user store. One issue
>>>>>> with
>>>>>> this approach is that brokered log out doesn't work. A potential
>>>>>> solution
>>>>>> to
>>>>>> that is that we only request offline access when linking the account,
>>>>>> but
>>>>>> during authentication don't add the offline scope and use the process
>>>>>> from
>>>>>> the first use-case.
>>>> I believe that brokered logout will work as long as we store the flag on
>>>> UserSession specifying which identity provider was used to authenticate
>>>> the user in particular session?
>>>>
>>>> For example if Google was used to authenticate user and Google offline
>>>> token was obtained during this authentication, then Keycloak logout will
>>>> propagate logout to the Google provider and invalidate Google offline
>>>> token as well. But if Google wasn't used for authenticating user in that
>>>> particular session (user already had offline Google token linked
>>>> previously to his account), then Keycloak logout won't propagate logout
>>>> to the Google and won't invalidate offline token.
>>>
>>> I don't think we should invalidate an offline token on logout. That should
>>> only be done by unlinking in the account management.
>>>
>>> We could request offline scope online when linking, which is stored in user
>>> store. If someone logs in with the same provider we don't request offline
>>> and store that token in user session.
>>>
>>
>> If offline is implemented as a persisted clone of UserSession, then
>> there is no extra work to be done.  UserSession already stores the
>> broker that logged in the user.  note.BROKER_PROVIDER_ID.
>
> There's two separate "offline" though:
>
> 1. App request offline access from Keycloak - this one makes with persisted clone of UserSession
> 2. Keycloak requests offline token from external IdP - how would this work with persisted clone of UserSession?
>

Why would Keycloak ever want an offline token?  Or an offline token not 
associated with a UserSession?  They only thing I could think of is if 
you want to bypass logging into the external IDP.

FYI, I think you're getting into some extreme edge cases.  Something I 
have no interest in implementing.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com