[keycloak-dev] Shouldn't external token by stored in UserSession?

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 24 March, 2015 2:12:45 PM
> Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession?
> 
> 
> 
> On 3/24/2015 8:40 AM, Stian Thorgersen wrote:
> > It's not specific to social brokering, the same use-case applies to any
> > IdP.
> >
> > There's two separate use-cases:
> >
> > * External IdP is used only to authenticate user (and logout) - in this
> > case I don't see why the app would need the token at all
> > * Application uses external token to invoke services
> >
> > The last use-case is the one I'm referring to and it doesn't just apply to
> > social brokering (that was just the example I used). An application may
> > want to invoke services secured by both the internal Keycloak and an
> > external IdP. This is the use-case where the application needs to obtain
> > the token from the external IdP. In this case the application quite likely
> > wants to have access to invoke the services independent of what mechanism
> > was used to authenticate the given session. In this case the external IdP
> > could be configured with the offline scope to provide permanent access.
> >
> 
> Again, right now, every brokered login *requires a user database write*.
>   This is unacceptable.
> 
> Untrue that the external token needs to be separate from user session.
> That's just the way it was initially decided to be implemented.  Flow
> should be:
> 
> 1. user logs in via external provide
> 2. external token stored in user session
> 3. App receives access token
> 
> The external token is either obtained by it being embedded in the app's
> access or ID token (which IMO is the best way to do it), or it is
> obtained via the token exchange service which *should*, IMO, require the
> app's acquired access token to retrieve the external token.
> 
> Offline access should just be a clone of the original userSession,
> access token, and refresh token.  That way our existing architecture can
> be used to manage "offline" tokens.

That's not going to work as UserSessions are lost in the case of a server restart/failure. Offline tokens and client grants needs to be persisted permanently. For example my phone has a offline token to my Google account and it's had it for more than a year now. I wouldn't want to re-enable that every time Google restarts the node that keeps my session. Maybe we need yet another (dread) storage option.

> 
> Also, finally, when the app refreshes its access token, OIDC brokered
> sessions should also check the timeout of the external refresh token and
> perform an external refresh if necessary.  This is absolutely needed as
> the external token may have been revoked.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>