[keycloak-dev] Identity Brokering token storage and retrieval

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> 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 at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> >> <keycloak-dev at lists.jboss.org>, "Bill Burke"
> >> <bburke at redhat.com>
> >> 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 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.
> >>>>
> >>>>
> >>>> 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?

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