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;, "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?