[Openid-specs-ab] HAL enhanced OAuth 2.0 response – Making OAuth 2.0 slightly more RESTful

Nat Sakimura sakimura at gmail.com
Thu Aug 30 22:52:30 UTC 2012


Note that in the last example, it is id_token and not access_token.

I may have distracted you but the main theme of the blog post was
actually not this resource identification issue but the hyperlink
driven uniform interface that makes use of the URL template.

=nat via iPhone

On Aug 31, 2012, at 5:44 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I understand that including the access token in the request URI makes it more restful, however it also makes it less secure than sending it as a header.
>
> Sending scopes as parameters would allow a sort of down scoping but I don't know really how useful that is.
>
> The access token may also be scoped for more than one Resource endpoint, though I personally prefer using token expansion to separate them.
>
> Where this might be useful is in the user info response for distributed claims.
> However passing the token as a query parameter is still not a good thing.
>
> John
>
> On 2012-08-30, at 11:22 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> (low priority and just for the sake of discussion)
>>
>> Continuing a little more on this thread after the conversation this morning:
>>
>> 1. About token response not having a unique associated identifiers.
>>
>> The resource we are talking about here is an abstract resource which
>> is being represented as the token response. The token response
>> actually has a unique URL at least in the code flow. It is:
>>
>>   https://example.com/token?code=asdfasdf
>>
>> 2. About userinfo endpoint being not bound to a resource
>>
>> If we regard the userinfo URL as
>>  http://example.com/userinfo?access_token=aCcEssTokEn
>> then, it is uniquely identifying the resource.
>>
>> It would be even better if it were like:
>>  http://example.com/userinfo?id_token=id.token.sig&scope=profile%20email
>>
>> Note: if we are using URI template and HAL, then we actually would not
>> need to define the userinfo endpoint API. href in the _link with the
>> relationship of "userinfo" would return something like
>> http://example.com/uinfo/{id_token}.{scope}
>> and it would have still worked equally.
>>
>> No. I am not proposing a change to userinfo endpoint.
>> It is actually easier for the client to just hard code the parameters
>> than parse the URI template.
>> However, it does seem to be an interesting thought expedient that I
>> may learn a little more about being RESTful.
>>
>> Nat
>>
>>
>> On Wed, Aug 29, 2012 at 12:54 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>> I created a new blog post: HAL enhanced OAuth 2.0 response – Making
>>> OAuth 2.0 slightly more RESTful
>>> http://nat.sakimura.org/2012/08/29/hal-enhanced-oauth-2-0-response/
>>>
>>> Food for your thought.
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


More information about the Openid-specs-ab mailing list