[keycloak-dev] token exchange

Bill Burke bburke at redhat.com
Wed Apr 1 10:48:04 EDT 2015


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


More information about the keycloak-dev mailing list