[keycloak-dev] Identity Brokering token storage and retrieval

[Marek Posolda]

On 23.4.2015 15:03, Bill Burke wrote:
>
> 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.
Yeah, which makes it tricky what exactly is "offline" token as it 
depends on the provider though. For example Twitter doesn't expire 
accessTokens, so in case of Twitter, each access token can be considered 
as "offline" token. Similarly for Facebook which doesn't support 
refresh, but access token are long-lived (like valid for 2 moths or so)...

Marek
>
> 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?
>
>>> 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?
>
>
>>> Token retrieval
>>> ---------------
>>> We add a "token service" client to Keycloak that has a "retrieve token" role
>>> for each provider. For an application to be able to retrieve the token the
>>> user has to have a role mapping on this role and the client has to have a
>>> scope on it as well. This results in using standard roles, scopes and
>>> consent screens instead of a different mechanism.
>>>
> I implemented it as one master role for reading the external token.
> Wouldn't this be better?  Isn't one role per provider too fine grained?
>    Think about social, you'd have to assign 6-7 different roles to the
> user.  Although doing a role per provider would definitely make it
> easier to implement as I wouldn't have to implement the migration stuff
> I emailed about the other day.
>
> BTW, I'm almost done with this. I ran into a problem testing where I
> uncovered a brokered logout bug and I've spent most of my time fixing that.
>
>