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
https://www.ietf.org/mailman/listinfo/oauth
