[Openid-specs-ab] HAL enhanced OAuth 2.0 response – Making OAuth 2.0 slightly more RESTful
ve7jtb at ve7jtb.com
Thu Aug 30 20:44:09 UTC 2012
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.
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:
> 2. About userinfo endpoint being not bound to a resource
> If we regard the userinfo URL as
> then, it is uniquely identifying the resource.
> It would be even better if it were like:
> 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
> 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.
> 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
>> Food for your thought.
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4937 bytes
Desc: not available
More information about the Openid-specs-ab