[keycloak-dev] Identity Brokering token storage and retrieval

[Bill Burke]

On 4/23/2015 9:13 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 23 April, 2015 3:03:07 PM
>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>>
>>
>> On 4/23/2015 1:52 AM, 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.
>>>>
>>
>> I don't know if SAML has refresh.  Half the social providers don't either.
>>
>> I'm a bit wary of automatic background refresh.  Every active
>> usersession would have to be polled periodically.  Don't know if that
>> would be a big performance issue or not.  Maybe just do on-demand
>> refresh checks?
>
> I thought that was how the brokered logout worked. I agree that a automatic background refresh would be crazy.
>
> How does the brokered logout actually work then?
>

I don't check external token expiration at the moment or do any refreshes.


>>
>>>>
>>>> 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.
>>>>
>>
>> If offline access is persisted, couldn't the external token still be
>> stored in the persisted UserSession?
>
> The offline token shouldn't be associated with a specific user session. It should be associated with a user.
>

See my other email.  If offline token is implemented as persisted cloned 
extension of UserSession, then everything will be available.


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