[keycloak-dev] token exchange

[Stian Thorgersen]

As I've said several times now there are two use-cases for tokens:

1. Authentication - here a IdP is used mainly to authenticate a user. The token can (and should probably) be kept in use session. In this case it makes perfect sense to refresh the token alongside the main token.

2. Access - here a IdP is used to gain access to external resources. In this case when a user links the account an offline token is obtained from the external IdP. This token has a long lifetime and has to be stored in user storage (user session is not permanent). In this case an application may use one or more offline tokens that are associated with the account. In this case logout of a user session should not log-out the external IdP as it was not used for authentication. In this case a token  should be refreshed when required by the application. A user account may be linked with multiple IdP each with an offline token, but that doesn't mean they are used all the time. This is not only for social, other IdPs have offline token support as well, we will also.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 4:48:04 PM
> Subject: [keycloak-dev] token exchange
> 
> Another reason not to store tokens in user storage:
> 
> * For saml and oidc at least, the token lifespan is tied to the parent
> IDP's UserSession lifetime.  If a logout is triggered at the parent IDP,
> then these tokens are no longer valid.
> * If a user relogins in, then the token is refreshed, which would
> require a database write to the usermodel.
> 
> 
> 
> On 4/1/2015 10:42 AM, Bill Burke wrote:
> > Also, a bunch of things about this Token Exchange service bug me making
> > me think we shouldn't expose it at this time.
> >
> > * External tokens shouldn't be stored in user storage.  While social
> > tokens are often long living, brokered tokens aren't.  They should
> > instead be stored in the UserSession.
> > * The current implementation of this service stores the entire
> > SAMLREsponse document for SAML, and the entire AccessTokenResponse for
> > OIDC.  Probably not the most user friendly or greatest idea.
> > * OIDC has two tokens.  IDToken and Access token.  Both might be needed
> > by client app or user.
> >
> 
> --
> 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
>