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

[Stian Thorgersen]

Another important thing that I've mentioned a few times that I feel you're ignoring. Storing the token in the user session makes perfect sense for the 1 token that used to login that session, but it does not make sense if a users account is linked with multiple IdPs and there's has an offline token from multiple IdPs. In that case if tokens are stored in the user session how would an application retrieve all of the offline tokens?!

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 24 March, 2015 3:37:54 PM
> Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession?
> 
> 
> 
> ----- 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
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>