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