[keycloak-dev] Identity Brokering token storage and retrieval

[Bill Burke]

On 4/23/2015 12:53 PM, Marek Posolda wrote:
> 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)
>

So I guess we just keep storing external "tokens" the way we are doing 
it: in the FederatedIdentityModel.  I'll add a "refresh" method to 
IdentityProvider interface that will be called by the refreshToken 
operation if the user is attached to an identity provider.

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