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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Marek Posolda" <mposolda(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Thursday, 23 April, 2015 3:07:21 PM Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval On 4/23/2015 6:40 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "keycloak dev" >> <keycloak-dev(a)lists.jboss.org&gt;, "Bill Burke" >> <bburke(a)redhat.com&gt; >> Sent: Thursday, 23 April, 2015 11:31:25 AM >> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval >> >> On 23.4.2015 07:52, 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. >>>> >>>> >>>> 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. >> I believe that brokered logout will work as long as we store the flag on >> UserSession specifying which identity provider was used to authenticate >> the user in particular session? >> >> For example if Google was used to authenticate user and Google offline >> token was obtained during this authentication, then Keycloak logout will >> propagate logout to the Google provider and invalidate Google offline >> token as well. But if Google wasn't used for authenticating user in that >> particular session (user already had offline Google token linked >> previously to his account), then Keycloak logout won't propagate logout >> to the Google and won't invalidate offline token. > > I don't think we should invalidate an offline token on logout. That should > only be done by unlinking in the account management. > > We could request offline scope online when linking, which is stored in user > store. If someone logs in with the same provider we don't request offline > and store that token in user session. > If offline is implemented as a persisted clone of UserSession, then there is no extra work to be done. UserSession already stores the broker that logged in the user. note.BROKER_PROVIDER_ID.

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