inline On 2013-02-18, at 11:31 AM, Justin Richer <[email protected]> wrote:
> > On 02/17/2013 05:54 AM, Torsten Lodderstedt wrote: >> Hi Justin, >> >> the new revision seems to catch the state of discussion and is consistent. >> Thank's for bringing this topic forward. >> >> On your editor's not in section 4.2.: In my opinion, the 404 due to a >> none-existing resource should precede the 403. I would suggest to point out >> your thoughts on the access token. But as with any HTTP request, there could >> be other ways to authenticate to this endpoint. I therefore would not >> connect both aspects to much. >> > > From our own implementation, the code that processes the token would fire > (and fail) long before the code that checks if the client is valid gets > reached. So for us, checking if the client exists in the first place is > difficult. > > What if we just say it's a 403 if either the client or the token are invalid? This is the wording I put in the Connect version When a read error condition occurs, the Client Registration Access Endpoint returns a HTTP 403 Forbidden status code. This indicates that the Access Token is invalid or the Client record requested is invalid or non-existent. Note that for security reasons, to inhibit brute force attacks, endpoints MUST NOT return 404 Not Found error codes. From a security point of view differentiating the two is bad as it helps an attacker find valid notes to brute force. Ideally you want an attacker to spend time truing to break into resources that don't exist as well as ones that do. John B.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
