[keycloak-dev] Identity Brokering token storage and retrieval
bburke at redhat.com
Thu Apr 23 09:03:07 EDT 2015
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.
>> 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
>> 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.
JBoss, a division of Red Hat
More information about the keycloak-dev