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

[John Bradley]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120830/46e68d37/attachment.p7s>