[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 15:22:21 UTC 2012


(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


More information about the Openid-specs-ab mailing list