Subject: [OAUTH-WG] Is it allow to add custom attribute to access token response?

From: Donghwan Kim <[email-masked]>
Date: Thu, 20 Aug 2015 23:15:40 +0900

Hi,

I would like to add a custom property representing the account who just
authenticated to the access token response for the sake of convenience like
login request's response. Then, an exchange of request and response will
look like this:

POST /tokens HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"grant_type":"password","username":"${username}","password":"${password}"}

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"${JSON web token}",
  "token_type":"Bearer",
  "account": {"username":"donghwan", ...}
}

However http://tools.ietf.org/html/rfc6749#section-5.1 says that

> The client MUST ignore unrecognized value names in the response.

Does it mean that I shouldn't add such property, 'account'? Though, I saw
Instagram API adds such custom property to access token response for the
same purpose from https://instagram.com/developer/authentication/ (Please
find 'snoopdogg' to see that token response.) If it's not allowed or
desirable, how should I add such information to the access token response?

BTW, I have some questions on usage of JSON web token with OAuth. Can I
post them here? If not, where should I do that?

Thanks,

-- Donghawn

---

From: Bill Mills <[email-masked]>
Date: Fri, 21 Aug 2015 16:25:07 +0000 (UTC)

You can do your own extension in your own app, just don't expect anyone else to use it.   Not understanding why you want this though, because you already had a username in the request so the client should know.
Take a look at the Token Introspection stuff, it might solve this for you a different way if I am guessing right on what you're trying to do. 

     On Friday, August 21, 2015 8:43 AM, Donghwan Kim <[email-masked]> wrote:

 Hi,

I would like to add a custom property representing the account who just authenticated to the access token response for the sake of convenience like login request's response. Then, an exchange of request and response will look like this:

POST /tokens HTTP/1.1Host: api.example.comContent-Type: application/json
{"grant_type":"password","username":"${username}","password":"${password}"}

HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-storePragma: no-cache
{  "access_token":"${JSON web token}",  "token_type":"Bearer",  "account": {"username":"donghwan", ...}}

> The client MUST ignore unrecognized value names in the response.
Does it mean that I shouldn't add such property, 'account'? Though, I saw Instagram API adds such custom property to access token response for the same purpose from https://instagram.com/developer/authentication/ (Please find 'snoopdogg' to see that token response.) If it's not allowed or desirable, how should I add such information to the access token response?
BTW, I have some questions on usage of JSON web token with OAuth. Can I post them here? If not, where should I do that?
Thanks,

-- Donghawn
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Denniss <[email-masked]>
Date: Fri, 21 Aug 2015 09:34:12 -0700

You can add additional parameters.

"The client MUST ignore unrecognized value names in the response" is there
so that other clients who don't understand your parameters will ignore
them. That line basically enables the behavior you wanted (if it said the
client must *error* on unrecognized values, that would be a problem).

It would be best if you tried to name your params to be hardened against
collision with any future extensions to OAuth/OpenID Connect (e.g., adding
a vendor prefix)

---

From: John Bradley <[email-masked]>
Date: Fri, 21 Aug 2015 13:35:48 -0300

Requests to the token endpoint are URL form encoded not JSON in your example.

The use of the password credentials grant was to allow migration from HTTP basic, but it not recommended for privacy and security reasons.

OpenID Connect is a better way to authenticate users.

However assuming you have a closed system and don’t care about interoperability between clients and the Token endpoint, you could just add that parameter to your AS and the world will not end.

If you want to have interoperable clients then you should register the new element in the IANA registry Sec 11.2 of the spec.

Parameter name:
      The name requested (e.g., “username").

   Parameter usage location:
      token response.

   Change controller:
      For Standards Track RFCs, state "IETF".  For others, give the name
      of the responsible party.  Other details (e.g., postal address,
      email address, home page URI) may also be included.
You need to have a specification to do that.

I don’t see this as a good idea, but that is how you would do it.

Regards
John B.

> On Aug 20, 2015, at 11:15 AM, Donghwan Kim <[email-masked]> wrote:
> 
> Hi,
> 
> Host: api.example.com <http://api.example.com/>
> However http://tools.ietf.org/html/rfc6749#section-5.1 <http://tools.ietf.org/html/rfc6749#section-5.1> says that
> 
> Does it mean that I shouldn't add such property, 'account'? Though, I saw Instagram API adds such custom property to access token response for the same purpose from https://instagram.com/developer/authentication/ <https://instagram.com/developer/authentication/> (Please find 'snoopdogg' to see that token response.) If it's not allowed or desirable, how should I add such information to the access token response?
>

---

From: John Bradley <[email-masked]>
Date: Fri, 21 Aug 2015 13:38:33 -0300

Yes going the unregistered route it is probably best to use a name in you namespace eg “com.example:username”.

> On Aug 21, 2015, at 1:34 PM, William Denniss <[email-masked]> wrote:
> 
> "The client MUST ignore unrecognized value names in the response" is there so that other clients who don't understand your parameters will ignore them. That line basically enables the behavior you wanted (if it said the client must *error* on unrecognized values, that would be a problem).
> 
> It would be best if you tried to name your params to be hardened against collision with any future extensions to OAuth/OpenID Connect (e.g., adding a vendor prefix)
> 
> On Thu, Aug 20, 2015 at 7:15 AM, Donghwan Kim <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Bill Mills <[email-masked]>
Date: Fri, 21 Aug 2015 16:41:21 +0000 (UTC)

And as John said, if you are doing user authentication use OpenID instead. 

     On Friday, August 21, 2015 9:38 AM, John Bradley <[email-masked]> wrote:

It would be best if you tried to name your params to be hardened against collision with any future extensions to OAuth/OpenID Connect (e.g., adding a vendor prefix)
On Thu, Aug 20, 2015 at 7:15 AM, Donghwan Kim <[email-masked]> wrote:

Hi,

-- Donghawn

---

From: William Denniss <[email-masked]>
Date: Fri, 21 Aug 2015 09:42:10 -0700

As for your specific use-case though, as John said it's better to use
OpenID Connect which provides a solution for what you are trying to do
already.

That way you get an interoperable solution, and one that has been vetted by
security experts. There is even a free test suite
<http://openid.net/certification/testing/> for you to test your
implementation.

On Fri, Aug 21, 2015 at 9:35 AM, John Bradley <[email-masked]> wrote:

> The use of the password credentials grant was to allow migration from HTTP
> basic, but it not recommended for privacy and security reasons.
>
> However assuming you have a closed system and don’t care about
> interoperability between clients and the Token endpoint, you could just add
> that parameter to your AS and the world will not end.
>
> If you want to have interoperable clients then you should register the new
> element in the IANA registry Sec 11.2 of the spec.
>
> Parameter name:

---

From: John Bradley <[email-masked]>
Date: Sun, 23 Aug 2015 15:37:36 -0300

OIDC returns a signed JWT/id_token from the token endpoint that can contain all of that information (no extra round trips).   Setting a id_token as a cookie is not unusual.   I would not conflate the access token with session tokens.

John B.

> On Aug 23, 2015, at 3:32 PM, Donghwan Kim <[email-masked]> wrote:
> 
> Hi folks,
> 
> First off, I appreciate your answers.
> 
> What I try to do with OAuth is to design a set of APIs which allow to write application without server in a standard-compliant way and I chose OAuth for the social web. Because the current API I work on uses a kind of Form-based authentication (https://en.wikipedia.org/wiki/Form-based_authentication <https://en.wikipedia.org/wiki/Form-based_authentication>), I started with Resource Owner Password Credentials first to support other grant types gracefully later. Here I faced the problem with authentication. (Now I realized that I may have abused OAuth according to your answers)
> 
> My thought is to use access_token as a session token containing values like roles not just a reference on server's memory indicating such values (traditional cookie). That means access_token should be a JSON Web Token (JWT) which contains usename (to log who did an action), roles (ACL, to determine this request has a proper permission), and so on. Then every server (or microservice unit) accepting request doesn't need to have not only session states in its memory (stateless), but also a dependency with auth server because access_token included in Authorization request header as bearer token contains all about authentication and authorization information. Having said that, because token would be not valid over time if values contained in the token might be changed e.g. role or due to OAuth's expiration mechanism, removing dependency with auth server is unlikely to be feasible practically IMO. (Then it would be better for access_token to be reference rather than a set of values)
> 
> As for the original question, as Bill pointed, it's okay to get user information by username through other separate endpoint for that purpose (like /userinfo from the context of OpenID Connect (OIDC)). Though, I wanted to reduce round-trip by adding a custom property to token endpoint's response.
> 
> Here's some questions:
> 
> 1. Is it an abuse of OAuth to use access_token as a session token which is a set of values not reference on server indicating values? or what if it is in the form of reference? As far as I read https://tools.ietf.org/html/rfc6749 <https://tools.ietf.org/html/rfc6749>, I didn't feel that access_token should not be like that. On the contrary, if I introduce another standard for authentication, API implementators should do more work and I didn't want to do that. In this case, support for OIDC can be regarded as enhancement of API like Google did https://developers.google.com/+/web/api/rest/openidconnect/ <https://developers.google.com/+/web/api/rest/openidconnect/>
> 
> If not or it doesn't sound that good, I'll take a look https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> and http://openid.net/specs/openid-connect-core-1_0.html <http://openid.net/specs/openid-connect-core-1_0.html> which you suggested. (Though I'm not comfortable that OIDC is also regarded abuse of OAuth according to http://security.stackexchange.com/a/44614 <http://security.stackexchange.com/a/44614>)
> 
> Thanks!
> 
> -- Donghwan
> 
> On Sat, Aug 22, 2015 at 1:42 AM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> As for your specific use-case though, as John said it's better to use OpenID Connect which provides a solution for what you are trying to do already.
> 
> That way you get an interoperable solution, and one that has been vetted by security experts. There is even a free test suite <http://openid.net/certification/testing/> for you to test your implementation.
> 
> On Fri, Aug 21, 2015 at 9:35 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 20, 2015, at 11:15 AM, Donghwan Kim <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>

---

From: Donghwan Kim <[email-masked]>
Date: Mon, 24 Aug 2015 03:32:33 +0900

Hi folks,

What I try to do with OAuth is to design a set of APIs which allow to write
application without server in a standard-compliant way and I chose OAuth
for the social web. Because the current API I work on uses a kind
of Form-based authentication (
https://en.wikipedia.org/wiki/Form-based_authentication), I started
with Resource Owner Password Credentials first to support other grant types
gracefully later. Here I faced the problem with authentication. (Now I
realized that I may have abused OAuth according to your answers)

My thought is to use access_token as a session token containing values like
roles not just a reference on server's memory indicating such values
(traditional cookie). That means access_token should be a JSON Web Token
(JWT) which contains usename (to log who did an action), roles (ACL, to
determine this request has a proper permission), and so on. Then every
server (or microservice unit) accepting request doesn't need to have not
only session states in its memory (stateless), but also a dependency with
auth server because access_token included in Authorization request header
as bearer token contains all about authentication and authorization
information. Having said that, because token would be not valid over time
if values contained in the token might be changed e.g. role or due to
OAuth's expiration mechanism, removing dependency with auth server is
unlikely to be feasible practically IMO. (Then it would be better for
access_token to be reference rather than a set of values)

As for the original question, as Bill pointed, it's okay to get user
information by username through other separate endpoint for that purpose
(like /userinfo from the context of OpenID Connect (OIDC)). Though, I
wanted to reduce round-trip by adding a custom property to token endpoint's
response.

Here's some questions:

1. Is it an abuse of OAuth to use access_token as a session token which is
a set of values not reference on server indicating values? or what if it is
in the form of reference? As far as I read
https://tools.ietf.org/html/rfc6749, I didn't feel that access_token should
not be like that. On the contrary, if I introduce another standard for
authentication, API implementators should do more work and I didn't want to
do that. In this case, support for OIDC can be regarded as enhancement of
API like Google did
https://developers.google.com/+/web/api/rest/openidconnect/

If not or it doesn't sound that good, I'll take a look
https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 and
http://openid.net/specs/openid-connect-core-1_0.html which you suggested.
(Though I'm not comfortable that OIDC is also regarded abuse of OAuth
according to http://security.stackexchange.com/a/44614)

Thanks!

-- Donghwan

On Sat, Aug 22, 2015 at 1:42 AM, William Denniss <[email-masked]>
wrote:

> That way you get an interoperable solution, and one that has been vetted
> by security experts. There is even a free test suite
>> The use of the password credentials grant was to allow migration from
>> HTTP basic, but it not recommended for privacy and security reasons.
>>
>> If you want to have interoperable clients then you should register the
>> new element in the IANA registry Sec 11.2 of the spec.
>>
>> Parameter name:
>> same purpose from https://instagram.com/developer/authentication/
>> (Please find 'snoopdogg' to see that token response.) If it's not allowed
>> or desirable, how should I add such information to the access token
>> response?
>>

---

From: Donghwan Kim <[email-masked]>
Date: Mon, 24 Aug 2015 15:13:01 +0900

Hi,

> Requests to the token endpoint are URL form encoded not JSON in your
example.

My bad.

According to http://tools.ietf.org/html/rfc6749#section-4.3,
application/x-www-form-urlencoded not application/json is correct for token
endpoint request's content type. Right?

Thanks,

-- Donghwan