[keycloak-dev] Identity Brokering token storage and retrieval

[Marek Posolda]

On 23.4.2015 16:30, Bill Burke wrote:
>
>
> 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.
>
I think it is about the possibility to use all the 3rd party tokens in 
one application. For example I have application secured by Keycloak, 
which wants to display list of my friends from Facebook and also from 
Google. On Monday I login into the application through Google. On 
Tuesday I login into that application from Facebook, but I still want to 
display my friends from both Facebook and Google. So application would 
need to have possibility to reuse the token obtained from Google the 
previous day.

Note that I want offline token from Google, but I don't need offline 
UserSession from Keycloak itself. Both Keycloak sessions from Monday and 
Tuesday are short lived (ie. I spent just 5 minutes playing with my 
application every day)

Marek