> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
