----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
Sent: Wednesday, 1 April, 2015 4:42:28 PM
Subject: Re: [keycloak-dev] Release status
Also, a bunch of things about this Token Exchange service bug me making
me think we shouldn't expose it at this time.
Agree there's some kinks we should work out, so let's hide the "store
tokens" option for an identity provider as well as the identity provider tab under
* 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.
Brokered tokens can be long living, for example offline tokens which we should add support
for in KC. As I've said before there's two use-cases for brokering one is
authentication the other is access. For access you quite likely want an offline token to
permanently get access to an external service after linking the account.
However, offline tokens will most likely be the exception not the rule, so I agree we
should store most tokens in user-session, but also have the ability to store offline
tokens in user storage (or another permanent store). By the way for a user session it
would only make sense to store a single token, which is the token used to authenticate
with, but when you're linking an account you may want to store an offline token.
* 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.
On 4/1/2015 10:32 AM, Bill Burke wrote:
> On 4/1/2015 10:29 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)lists.jboss.org
>>> Sent: Wednesday, 1 April, 2015 4:22:42 PM
>>> Subject: Re: [keycloak-dev] Release status
>>> No, I don't. I"ll look into it after I finish this one thing.
>>> Probably should be implemented differently anyways. Token exchange
>>> service should be an application with a role that can be assigned to
>>> user or applied via a protocol mapper.
>> Yes, token exchange service as app and role sounds much better. That would
>> let you control what users (role-mapping) and apps (scope) that are
>> allowed to access it. Would also work with existing grant features if an
>> "oauth client" request access. Shame we don't have time to change
>> as it'll probably be a bit of work?!
> Can't be done by tomorrow. Should I just disable the identity provider
> tab until we do this? Or are users asking for access to external tokens?
JBoss, a division of Red Hat
keycloak-dev mailing list