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

[Donghwan Kim <[e-mail]>]

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), 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 <[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]> 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]>
>> 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
>> 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
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>