1:55 a.m.
As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If
I've read the spec correctly those claims should only be in the ID Token. There should
also be a separate UserInfo endpoint which we're missing.
Is there a reason why AccessToken extends IDToken, or can we remove that?
5:28 a.m.
I notice that too when trying to broker a KeyCloak server from another one.
Also, I think KC is missing OpenID Connect Discovery [1].
[1] http://openid.net/specs/openid-connect-discovery-1_0.html
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Wednesday, December 3, 2014 5:55:24 AM
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If
I've read the spec correctly those claims should only be in the ID Token. There should
also be a separate UserInfo endpoint which we're missing.
Is there a reason why AccessToken extends IDToken, or can we remove that?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:32 a.m.
----- Original Message -----
From: "Pedro Igor Silva" <psilva(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Wednesday, 3 December, 2014 12:28:11 PM
Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
I notice that too when trying to broker a KeyCloak server from another one.
Also, I think KC is missing OpenID Connect Discovery [1].
[1] http://openid.net/specs/openid-connect-discovery-1_0.html
Yep, we've only implemented the core spec and parts of the session spec.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Wednesday, December 3, 2014 5:55:24 AM
Subject: [keycloak-dev] ID Token claims in Access Token and Refresh Token
As AccessToken and RefreshToken extends IDToken they contain the ID Token
claims. If I've read the spec correctly those claims should only be in the
ID Token. There should also be a separate UserInfo endpoint which we're
missing.
Is there a reason why AccessToken extends IDToken, or can we remove that?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:39 a.m.
The one reason I can think of is bearer authentication. Currently we are
doing it with accessToken and if we remove claims from accessToken, then
bearer app won't be able to easily retrieve informations about user
without sending another request to UserInfo endpoint. I agree that
having userInfo in all tokens doesn't makes much sense, but not sure how
to improve it. Some options:
1) Remove IDToken (but I guess we need it for OpenID connect support,
right?)
2) Send both accessToken+idToken to bearer auth (but there is more
network bandwith then)
3) Allow bearer apps to retrieve data from UserInfo, but that's another
request to KC needed then
4) Keep as it is.
For UserInfo we have endpoint on AccountManagement, which is used for
example by keycloak.js (Keycloak.loadUserProfile). Or do you mean
something different?
Marek
On 3.12.2014 08:55, Stian Thorgersen wrote:
As AccessToken and RefreshToken extends IDToken they contain the ID
Token claims. If I've read the spec correctly those claims should only be in the ID
Token. There should also be a separate UserInfo endpoint which we're missing.
Is there a reason why AccessToken extends IDToken, or can we remove that?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:58 a.m.
I wonder if we can have it configurable if IDToken is sent or not? The
only reason to have it enabled is for specs compliance afaik, but for
Keycloak itself it doesn't need to be needed anywhere as data are on
access token. Also removing user claims from refresh token makes sense
anyway to me. It needs to keep only stuff, which is needed by Keycloak
to refresh new set of tokens (like sessionId, expiration etc).
On 3.12.2014 14:39, Marek Posolda wrote:
The one reason I can think of is bearer authentication. Currently we
are
doing it with accessToken and if we remove claims from accessToken, then
bearer app won't be able to easily retrieve informations about user
without sending another request to UserInfo endpoint. I agree that
having userInfo in all tokens doesn't makes much sense, but not sure how
to improve it. Some options:
1) Remove IDToken (but I guess we need it for OpenID connect support,
right?)
2) Send both accessToken+idToken to bearer auth (but there is more
network bandwith then)
3) Allow bearer apps to retrieve data from UserInfo, but that's another
request to KC needed then
4) Keep as it is.
For UserInfo we have endpoint on AccountManagement, which is used for
example by keycloak.js (Keycloak.loadUserProfile). Or do you mean
something different?
Marek
On 3.12.2014 08:55, Stian Thorgersen wrote:
> As AccessToken and RefreshToken extends IDToken they contain the ID Token claims. If
I've read the spec correctly those claims should only be in the ID Token. There should
also be a separate UserInfo endpoint which we're missing.
>
> Is there a reason why AccessToken extends IDToken, or can we remove that?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:01 a.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "keycloak dev"
<keycloak-dev(a)lists.jboss.org>
Sent: Wednesday, 3 December, 2014 2:39:14 PM
Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
The one reason I can think of is bearer authentication. Currently we are
doing it with accessToken and if we remove claims from accessToken, then
bearer app won't be able to easily retrieve informations about user
without sending another request to UserInfo endpoint. I agree that
having userInfo in all tokens doesn't makes much sense, but not sure how
to improve it. Some options:
1) Remove IDToken (but I guess we need it for OpenID connect support,
right?)
2) Send both accessToken+idToken to bearer auth (but there is more
network bandwith then)
3) Allow bearer apps to retrieve data from UserInfo, but that's another
request to KC needed then
4) Keep as it is.
It would reduce the size of the access token. Could be by quite a few bytes when
there's more and more claims added. Question is how does REST endpoints expect to
retrieve these claims, and how many REST endpoints actually use the claims at all? Not
sure how you would send the token separately as it's expected the authorization header
contains the bearer token only.
For UserInfo we have endpoint on AccountManagement, which is used for
example by keycloak.js (Keycloak.loadUserProfile). Or do you mean
something different?
Something else as it should be OpenID Connect specific with the same fields as the ID
Token.
Marek
On 3.12.2014 08:55, Stian Thorgersen wrote:
> As AccessToken and RefreshToken extends IDToken they contain the ID Token
> claims. If I've read the spec correctly those claims should only be in the
> ID Token. There should also be a separate UserInfo endpoint which we're
> missing.
>
> Is there a reason why AccessToken extends IDToken, or can we remove that?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:15 a.m.
On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Marek Posolda" <mposolda(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>, "keycloak dev"
<keycloak-dev(a)lists.jboss.org>
> Sent: Wednesday, 3 December, 2014 2:39:14 PM
> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
>
> The one reason I can think of is bearer authentication. Currently we are
> doing it with accessToken and if we remove claims from accessToken, then
> bearer app won't be able to easily retrieve informations about user
> without sending another request to UserInfo endpoint. I agree that
> having userInfo in all tokens doesn't makes much sense, but not sure how
> to improve it. Some options:
> 1) Remove IDToken (but I guess we need it for OpenID connect support,
> right?)
> 2) Send both accessToken+idToken to bearer auth (but there is more
> network bandwith then)
> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
> request to KC needed then
> 4) Keep as it is.
It would reduce the size of the access token. Could be by quite a few bytes when
there's more and more claims added. Question is how does REST endpoints expect to
retrieve these claims, and how many REST endpoints actually use the claims at all? Not
sure how you would send the token separately as it's expected the authorization header
contains the bearer token only.
You can currently control per client what exactly goes in the access token.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:34 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 3 December, 2014 3:15:05 PM
Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>, "keycloak
dev"
>> <keycloak-dev(a)lists.jboss.org>
>> Sent: Wednesday, 3 December, 2014 2:39:14 PM
>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
>> Token
>>
>> The one reason I can think of is bearer authentication. Currently we are
>> doing it with accessToken and if we remove claims from accessToken, then
>> bearer app won't be able to easily retrieve informations about user
>> without sending another request to UserInfo endpoint. I agree that
>> having userInfo in all tokens doesn't makes much sense, but not sure how
>> to improve it. Some options:
>> 1) Remove IDToken (but I guess we need it for OpenID connect support,
>> right?)
>> 2) Send both accessToken+idToken to bearer auth (but there is more
>> network bandwith then)
>> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
>> request to KC needed then
>> 4) Keep as it is.
>
> It would reduce the size of the access token. Could be by quite a few bytes
> when there's more and more claims added. Question is how does REST
> endpoints expect to retrieve these claims, and how many REST endpoints
> actually use the claims at all? Not sure how you would send the token
> separately as it's expected the authorization header contains the bearer
> token only.
>
You can currently control per client what exactly goes in the access token.
That doesn't really help. A front-end app may for example want the full profile, but
if it does that means the token it sends with all requests is bigger as well.
--
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
1 p.m.
On 12/3/2014 9:34 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Wednesday, 3 December, 2014 3:15:05 PM
> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
>
>
>
> On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>, "keycloak
dev"
>>> <keycloak-dev(a)lists.jboss.org>
>>> Sent: Wednesday, 3 December, 2014 2:39:14 PM
>>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
>>> Token
>>>
>>> The one reason I can think of is bearer authentication. Currently we are
>>> doing it with accessToken and if we remove claims from accessToken, then
>>> bearer app won't be able to easily retrieve informations about user
>>> without sending another request to UserInfo endpoint. I agree that
>>> having userInfo in all tokens doesn't makes much sense, but not sure how
>>> to improve it. Some options:
>>> 1) Remove IDToken (but I guess we need it for OpenID connect support,
>>> right?)
>>> 2) Send both accessToken+idToken to bearer auth (but there is more
>>> network bandwith then)
>>> 3) Allow bearer apps to retrieve data from UserInfo, but that's another
>>> request to KC needed then
>>> 4) Keep as it is.
>>
>> It would reduce the size of the access token. Could be by quite a few bytes
>> when there's more and more claims added. Question is how does REST
>> endpoints expect to retrieve these claims, and how many REST endpoints
>> actually use the claims at all? Not sure how you would send the token
>> separately as it's expected the authorization header contains the bearer
>> token only.
>>
>
> You can currently control per client what exactly goes in the access token.
That doesn't really help. A front-end app may for example want the full profile, but
if it does that means the token it sends with all requests is bigger as well.
And that matters because? You're talking about bytes here...not
kilobytes, not megabytes. Really, this is a non-issue. Isn't there
other things to work on?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:41 a.m.
----- 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, 3 December, 2014 8:00:51 PM
Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh Token
On 12/3/2014 9:34 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 3:15:05 PM
>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
>> Token
>>
>>
>>
>> On 12/3/2014 9:01 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda(a)redhat.com>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>,
"keycloak dev"
>>>> <keycloak-dev(a)lists.jboss.org>
>>>> Sent: Wednesday, 3 December, 2014 2:39:14 PM
>>>> Subject: Re: [keycloak-dev] ID Token claims in Access Token and Refresh
>>>> Token
>>>>
>>>> The one reason I can think of is bearer authentication. Currently we
are
>>>> doing it with accessToken and if we remove claims from accessToken,
then
>>>> bearer app won't be able to easily retrieve informations about user
>>>> without sending another request to UserInfo endpoint. I agree that
>>>> having userInfo in all tokens doesn't makes much sense, but not sure
how
>>>> to improve it. Some options:
>>>> 1) Remove IDToken (but I guess we need it for OpenID connect support,
>>>> right?)
>>>> 2) Send both accessToken+idToken to bearer auth (but there is more
>>>> network bandwith then)
>>>> 3) Allow bearer apps to retrieve data from UserInfo, but that's
another
>>>> request to KC needed then
>>>> 4) Keep as it is.
>>>
>>> It would reduce the size of the access token. Could be by quite a few
>>> bytes
>>> when there's more and more claims added. Question is how does REST
>>> endpoints expect to retrieve these claims, and how many REST endpoints
>>> actually use the claims at all? Not sure how you would send the token
>>> separately as it's expected the authorization header contains the
bearer
>>> token only.
>>>
>>
>> You can currently control per client what exactly goes in the access
>> token.
>
> That doesn't really help. A front-end app may for example want the full
> profile, but if it does that means the token it sends with all requests is
> bigger as well.
>
And that matters because? You're talking about bytes here...not
kilobytes, not megabytes. Really, this is a non-issue. Isn't there
other things to work on?
I'm just asking questions and discussing something that wasn't clear to me!
Bytes do add up and I believe we have to be careful about what we put into the tokens, but
yes I totally agree we have more important things to work on.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:12 a.m.
On 12/3/2014 8:39 AM, Marek Posolda wrote:
4) Keep as it is.
We will keep it as is. Going back to the auth server every request to
obtain role mappings and user information is counter to what we are
trying to accomplish.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:10 a.m.
On 12/3/2014 2:55 AM, Stian Thorgersen wrote:
As AccessToken and RefreshToken extends IDToken they contain the ID
Token claims. If I've read the spec correctly those claims should only be in the ID
Token. There should also be a separate UserInfo endpoint which we're missing.
access and refresh tokens are opaque. We can put anything we want in them.
Is there a reason why AccessToken extends IDToken, or can we remove
that?
Please don't remove it. AccessToken extends IDTOken so that we can
propagate stuff with bearer token auth. Refresh token needs much of the
same information as JWT, expiration, subject, roles granted, claims
granted so it can make decisions on whether to refresh the token or not.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3693
days inactive
3694
days old
11 comments
4 participants
participants (4)
-
Bill Burke -
Marek Posolda -
Pedro Igor Silva -
Stian Thorgersen