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

On 4/23/2015 10:12 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> 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. > > There's two separate "offline" though: > > 1. App request offline access from Keycloak - this one makes with > persisted clone of UserSession > 2. Keycloak requests offline token from external IdP - how would this > work with persisted clone of UserSession? > Why would Keycloak ever want an offline token? Or an offline token not associated with a UserSession? They only thing I could think of is if you want to bypass logging into the external IDP. FYI, I think you're getting into some extreme edge cases. Something I have no interest in implementing.