[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