[keycloak-dev] Identity Brokering token storage and retrieval

[Bill Burke]

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.


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