Subject: [OAUTH-WG] Inconsistent error responses between 6749 and 6750

From: George Fletcher <[email-masked]>
Date: Mon, 17 Sep 2018 09:45:44 -0400

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.

Thanks,
George

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 17 Sep 2018 16:22:49 +0200

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

---

From: LARMIGNAT Louis <[email-masked]>
Date: Mon, 17 Sep 2018 14:24:00 +0000

Hi Fletcher,

Actually we are not in the same case.
The /token endpoint is a protected ressource in regard to the client application. The credentials are the client id and, in the case of confidential clients, the client secret .
The OAuth 2.0 ressource is protected in regard to the user. The credential is the AT.

If your client id and your client secret are right, you are allowed to call the /token endpoint. The content of the request is a different matter.

Regards,

-----Message d'origine-----
De : OAuth <[email-masked]> De la part de George Fletcher
Envoyé : lundi 17 septembre 2018 15:46
À : [email-masked]
Objet : [OAUTH-WG] Inconsistent error responses between 6749 and 6750

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.

Thanks,
George

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth
The information transmitted in the present email including the attachment is intended only for the person to whom or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the material.

Ce message et toutes les pièces qui y sont éventuellement jointes sont confidentiels et transmis à l'intention exclusive de son destinataire. Toute modification, édition, utilisation ou diffusion par toute personne ou entité autre que le destinataire est interdite. Si vous avez reçu ce message par erreur, nous vous remercions de nous en informer immédiatement et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.

---

From: George Fletcher <[email-masked]>
Date: Mon, 17 Sep 2018 11:07:56 -0400

On 9/17/18 10:22 AM, Thomas Broyer wrote:
>
>
> On Mon, Sep 17, 2018 at 3:46 PM George Fletcher 
> <gffletch=[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi,
>
> 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