Re: [keycloak-dev] token exchange
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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev