I see how this could be confusing, so I'll make a note to clarify it. However, the only two error codes that would be returned from the authorization endpoint would be HTTP 200 or 302, because this is always returned to the browser, not to the OAuth client.
In the case of the authorization server communicating the error to the user, that would be HTTP 200 so that their browser will render the page rather than show its own error. In the case of the authorization server communicating the error to the client, it would of course have to send HTTP 302 so that the browser is redirected to the client. I do see the HTTP 302 included as an example in 4.1.2.1 but I agree this could be made more explicit, thanks! Aaron On Sat, Feb 12, 2022 at 6:50 PM <donald.cof...@reminetworks.com> wrote: > Section 5.2. Error Response for the Token Endpoint states: > > > > The authorization server responds with an HTTP 400 (Bad Request) > > status code (unless specified otherwise) and includes the following > > parameters with the response: > > > "error": REQUIRED. A single ASCII [USASCII > <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-01#ref-USASCII>] > error code from the > > Following: > > > (error list omitted for breviate) > > > > Section 4.1.2.1. Error Response for the Authorization Endpoint contains the > > Same error list but no direction about what HTTP status code should be > returned. > Wouldn’t it be helpful in the OAuth 2.1 draft to enhance section 4.1.2.1. > Error > > Response with the same or similar guidance regarding the current HTTP status > code > > to return? > > > > > > > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > > > REMI Networks > > 2335 Dunwoody Crossing Suite E > > Dunwoody, GA 30338-8221 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
