Re: [keycloak-dev] Identity Brokering token storage and retrieval

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > 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(a)redhat.com&gt; >>> To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>> 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.