The response from the RS is not the purview of the core OAuth framework RFC6749 but the token presentation, RFC6750, which has this to say on the matter:
When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response: Basically, it’s not the job of the token layer to dictate what the API’s response codes are, or how they’re used. Honestly, having the “error codes” at listed is a bit awkward because the RFC can’t say how those codes are returned “in the response” in a way that makes sense for the API. While the spec is talking about an HTTP WWW-Authenticate header field, it could also be returned elsewhere. Are we talking in a JSON object? In an XML document? In some other header field? Anything could be most appropriate for a given API, including more that I can’t think of here. That said, in practice you see a lot of JSON-based APIs these days that have a simple object with an “error” field that uses these common values, so even though it’s API-specific you do at least see some common behavior in addition to the header. Since RFC6749 and RFC6750 are being combined into 2.1, I would expect this approach to continue. It might be a good question to ask of the editors of 2.1 at the meeting next week. — Justin On Jul 20, 2022, at 10:46 AM, João Craveiro <h...@jcraveiro.com<mailto:h...@jcraveiro.com>> wrote: Hi list, I’ve been exploring the current OAuth 2.1 draft particularly deep to prepare some didactic material, and from that exploration the following stood out as being IMO worthy of some discussion. It’s specifically (as the subject points out) about Section 5.2.3 (accessing protected resources). 1. Failure to access a resource may not be due to insufficient scope, but to insufficient permission. E.g. a request to Google’s Drive API GET /files/:fileId endpoint might have the appropriate …/auth/drive scope, but the user doesn’t have the permission to see that specific file. Would this deserve its own mention, or is this still considered insufficient scope (with the unfortunate reality that there’s no scope allowing the resource owner to read a file they weren’t given access to)? 2. Still on the above, masking 403s as 404s is a widely used and accepted practice, which even the HTTP specification foresees (RFC 9110, §15.5.4): > An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). That’s in fact what happens in the Google Drive API example above. Since OAuth 2.1 is (unlike 2.0) venturing into providing guidance on this matter, would it make sense to include this possibility for completeness sake? OAuth 2.0 leaves error message specifics out of scope (cf. RFC 6749, §7.2), so any change here to reflect current practice / advice wouldn’t break OAuth 2.1’s backwards compatibility. Please me know your thoughts and/or any way I can actively contribute to improving this in the future OAuth version. Cheers, Cravvie — João Craveiro https://jcraveiro.com _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
