oauth2: id_ext not present on /oauth2/introspect or /warden/token/valid

[waynerobinson]

Only the at_ext values are present inside the extra key when requesting tokens from these endpoints.

id_ext values passed back in the consent token don't appear to be returnable.

[aeneasr]

The reasoning behind this is that the id token is self-contained but the access token is not. If you are allowed to receive an id token, you can extract the information from it. The access token has a different scope which is delegation of authorization. As that token is not self-contained, the information is provided at the endpoints.

The id token is, in general, just a flow to let third parties use OAuth2 for delegation of authentication, without being vulnerable to token substitution attacks. I don't think that the id token should be used to transport information not relevant to this task.

[waynerobinson]

It's more the stuff that's in the ID token is also relevant to be used
elsewhere. For us, it's a role_id which we need in the final token
exchange, but also when we verify the token afterwards. I don't understand
why it wouldn't be included afterwards.

What is your use case for id_ext values that wouldn't be useful to a normal
token introspection?

On Friday, 7 October 2016, Aeneas notifications@github.com wrote:

The reasoning behind this is that the id token is self-contained but the
access token is not. If you are allowed to receive an id token, you can
extract the information from it. The access token has a different scope
which is delegation of authorization. As that token is not self-contained,
the information is provided at the endpoints.

The id token is, in general, just a flow to let third parties use OAuth2
for delegation of authentication, without being vulnerable to token
substitution attacks. I don't think that the id token should be used to
transport information not relevant to this task.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#290 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAG4phQjZjG3fpnWIEXsirbmx2_115sKks5qxg_hgaJpZM4KQrEx
.

[aeneasr]

Usually, everything that is included in the id_ext claim should have the consent of the user. In case of roles this could be a scope like user.roles.read. ID Tokens usually have information like email, profile picture, name which are can be used to set up a new account in the third party app, if the subject of the id token is unknown.

Think of it as something that you would do if you use log in with google. It will give you some basic information that you can use in your log in or sign up endpoint.

[aeneasr]

The abstract of the specification is:

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

[waynerobinson]

I understand. But then how do I access things like email, profile pics, etc
from the internal apps that just have the access token and not the open ID
one without having to manually find that info itself. I'm not saying we
couldn't, but we have to verify the token anyway and always, may as well
include the data again in that.

Although I can partially understand in that statement I just made why you
wouldn't want to. Because of size/performance constraints.

You can close this issue if you like. I now understand the design decision
and will take that into account when we submit some documentation PRs. ;-)

On Friday, 7 October 2016, Aeneas notifications@github.com wrote:

Usually, everything that is included in the id_ext claim should have the
consent of the user. In case of roles this could be a scope like
user.roles.read. ID Tokens usually have information like email, profile
picture, name which are can be used to set up a new account in the third
party app, if the subject of the id token is unknown.

Think of it as something that you would do if you use log in with google.
It will give you some basic information that you can use in your log in or
sign up endpoint.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#290 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAG4pvbMWV4ws7uIBk7LkcKaCSXqP9Rlks5qxh-KgaJpZM4KQrEx
.

[aeneasr]

I understand. But then how do I access things like email, profile pics, etc from the internal apps that just have the access token and not the open ID one without having to manually find that info itself. I'm not saying we couldn't, but we have to verify the token anyway and always, may as well include the data again in that.

This really depends, keep in mind that email etc should only be included if the right scopes where set during the initial oauth2 request. So that data might not be available at all. It really depends on your use case and if it makes more sense to include this in the access token validation response or in a separate request. I don't think that I can give a one-fits all recommendation here, sorry :/

I now understand the design decision and will take that into account when we submit some documentation PRs. ;-)

This would be so awesome.

Closing, because I don't think I can help any further with this issue.