Re: [OAUTH-WG] 'Scope' parameter proposal

["Manger, James H" <[e-mail]>]

Eran,

>> "authz-uri=http://as.example.com/?scope=x2"
>> vs "authz-uri=http://as.example.com/" and "scope=x2"

> - How is this proposal *better* than a separate scope parameter?

1 field is simpler than 2.

> Your proposal will produce a shorter specification,
> but not a simpler developer experience.

It is no simpler for service developers -- these still need to agree on how to organize scopes/permissions with their authorization server.

It will be simpler for client developers. The concept of scopes disappears when they access services that they don't have service-specific knowledge about.

Developers writing for a specific service get a set of authorization URIs from the service's docs covering the different scopes (resources/permission/durations/...). Getting a set of URIs vs a base URI and a set of scopes is a trivial (or non-existent) difference.


> - How can the client tell if a token it already has is valid for a given protected resource?

This is absolutely required -- before making the request (ie before exposing the token).
My suggestion (in the "application/credentials" thread) is to include a list of locations whenever a token is issued. For example, a response to an access token request could include:
  "sites":["https://api.example.com", "http://photo.example.com"]



> Because there is no scope parameter, a client is forced to always get a new token when a request fails. I expect servers to issue tokens and say what they are for. For example, when returning an access token the server will include a scope=a,b,c. When the client is faced with an authentication challenge requiring a token capable of a and b, it knows it already have such a token. Clients can end up with multiple tokens, each with a different scope. This is a useful property of the protocol. It should be able to tell which token to use where.


This sounds messy. A client might get "red", "blue", and "green" tokens all for the same resources. It cannot tell which is appropriate for any given request until a 401 response tells it. Yuck. This might allow tokens-of-least-privilege, but to be usable it demands far more extensive "discovery" mechanisms than per-request 401 responses.

A far more likely approach is that an existing token is upgraded to a more powerful token (more scopes) as required. In this situation, a client need to say to the authorization server (via a user):
  "Please authorize {stuff the resource server said I need}, I already have {stuff you gave me previously}."

A single authz-uri in a 401 response can encode "{stuff the resource server said I need}".
A existing token (or an identifier for such a token) can encode "{stuff you gave me previously}".

Client developers should not be burdened with the internal structure of the "stuff" without a good reason.

--
James Manger

> -----Original Message-----
> From: Manger, James H [mailto:[e-mail]]
> Sent: Monday, April 19, 2010 9:06 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] 'Scope' parameter proposal
> 
> >    HTTP/1.1 401 Unauthorized
> >    WWW-Authenticate: Token realm='Example', scope='x2'
> 
> I assume the WWW-Authenticate response header also has an "authz-uri"
> parameter.
> 
>      WWW-Authenticate: Token realm='Example', scope='x2', authz-
> uri="https://as.example.com/"
> 
> The first time a client app gets this response all it can do is add the 'scope' to
> the 'authz-uri'. In which case the separate 'scope' parameter offered no
> advantage. The resource server could have more simply returned:
> 
>      WWW-Authenticate: Token realm='Example', authz-
> uri="https://as.example.com/?scope=x2"
> 
> 
> The one situation where a 'scope' parameter can help interop (between
> client with no server-specific knowledge and the server) is when scopes are
> combined.
> 
> A client with a token for scope 'x1' that receives a 401 can request a new
> token that includes the extra scope 'x2' as well. Even in this situation,
> defining a 'scope' parameter is not necessary. The resource server knows the
> offered token was for scope 'x1', but scope 'x2' is required so the response
> can be:
> 
>      WWW-Authenticate: Token realm='Example', authz-
> uri="https://as.example.com/?scope=x2,x1"
> 
> The client just sees a URI and uses it to get a new token. This approach might
> require some resource servers to dynamically generate the 'authz-uri' value
> in error responses. I doubt that is too onerous.
> 
> 
> An alternative way to support combining scopes would be to include (or
> reference) an existing token when requesting a new one. For instance,
> define an 'access_token' parameter to include when redirecting a user to the
> AS. This would work for updating a token for another 'scope', for a longer
> duration, for extra 'permissions' etc.
> This is not absolutely necessary to define this extra 'access_token' parameter
> since the resource server could dynamically insert the current token into the
> returned 'authz_uri' value by itself, without requiring client code to do so.
> Another difficulty is that some access_tokens should not be exposed to
> users. There may need to be an 'access_token_id' separate from the actual
> 'access_token' value.
> 
> 
> In conclusion,
> * -1 to Eran’s 'scope' proposal;
> * perhaps add explicit support for updating a token (as opposed to
> refreshing) by referencing an existing token when getting a new one.
> 
> 
> --
> James Manger
>