On 9/17/18 10:22 AM, Thomas Broyer wrote:
On Mon, Sep 17, 2018 at 3:46 PM George Fletcher
<gffletch=40aol....@dmarc.ietf.org <mailto:40aol....@dmarc.ietf.org>>
wrote:
Hi,
It appears that RFC 6749 and RFC 6750 are inconsistent in regards
to the
HTTP status code that should be returned when a requested scope is
"invalid".
For example, if a call is make to the /token endpoint to obtain a new
access_token and the scopes requested are outside those issued to the
refresh_token, RFC 6749 says the HTTP status code returned should
be 400
(Bad Request).
However, if an access token is presented to an OAuth2 protected
resource
and the access token does not contain the necessary scope, RFC
6750 says
the HTTP status code returned should be 403 (Forbidden).
Does anyone remember if this is intentional? The two cases here are
pretty equivalent semantic-wise.
How so‽
In the first case, you have a valid refresh_token and want to obtain
an access_token out of it. Assuming the client correctly
authenticated, it is authorized to make this request, but the request
is then rejected due to its payload/content. It could equally be a
422: the reason it's rejected is not about authentication or
authorization, but because it's a "bad request", it's "semantically
wrong".
In the second case, the token is used to authorize the request at the
RS, whatever the semantics of the request is (once authorized). If the
token is valid but doesn't authorize the request, then a 403 is
appropriate.
I see your point, but I guess I see it a little differently... in the
first case, the requests fails because the request is not authorized
based on the specified parameters. Because the requested scope is not
authorized by the supplied refresh_token, the request is not really a
"Bad Request" in the sense that incorrect parameters were supplied. All
the parameters are correct and have valid values. However, the values
supplied are not allowed by the Authorization Server. Basically the
request fails the AS authorization policy. Maybe there is a fine-grain
nuance in how authorization failures are returned:)
That said, the AS can legally return a 400 even if the client
authentication credentials are invalid if the authentication credentials
are specified as parameters rather than in the Authorization header. So
in reality, the only time the /token endpoint MUST return anything other
than a 400 is if the client credentials are both specified in the
Authorization header AND invalid.
Thanks,
George
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
