[keycloak-dev] Identity Brokering token storage and retrieval
stian at redhat.com
Thu Apr 23 09:13:13 EDT 2015
----- 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?
> >> 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.
> >> 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.
I guess that's fine for now, no need to over complicate things if not necessary - we can just see if anyone complains and wants something more fine-grained.
> 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.
> Bill Burke
> JBoss, a division of Red Hat
More information about the keycloak-dev