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

Torsten Lodderstedt torsten at lodderstedt.net
Sat Sep 1 07:54:28 UTC 2012

Hi Nat,

in my opinion, the resource should be


The authorization of this request is orthogonal. So including a token 
via request header fits in very well.


Am 30.08.2012 17:22, schrieb Nat Sakimura:
> (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

More information about the Openid-specs-ab mailing list