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

[Eran Hammer-Lahav <[e-mail]>]

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

Instead of giving developers an outline of how to implement scope, you are basically saying that they can already do with without an extra protocol parameter and should go figure it out on their own (your proposal is pattern, not normative language). The group seems set on the need to have a scope parameter (unless you can convince them otherwise). Your proposal will produce a shorter specification, but not a simpler developer experience.

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

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.

EHL

> -----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
>