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

[John Bradley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 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 <[e-mail] <mailto:[e-mail]>> 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.1
>> Host: api.example.com <http://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 <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/ <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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
>