Jerome, If you redirect an error of any sort to the redirect_uri in the authorization request if the client_id is wrong or the URI doesn't match the registered one you are creating a open redirector that can potentially be used for phasing or other attacks.
The redirect URI are registered to prevent that. Not sending a response is intentional. Regards John B. On 2012-07-04, at 1:31 PM, Torsten Lodderstedt wrote: > Hi Jerome, > > I read the introduction of 4.1.2.1 as follows: The authorization server shall > display an error message to the end-user. So no HTTP error code required. > > best regards, > Torsten. > > Am 21.06.2012 21:40, schrieb Jérôme LELEU: >> Hi, >> >> I'm trying to implement OAuth 2.0 provider support and, in particular, right >> handling of errors. >> >> Following OAuth 2.0 spec : >> http://tools.ietf.org/html/draft-ietf-oauth-v2-28, I don't understand the >> authorization request errors : part 4.1.2.1. >> If I have a valid redirection url, I understand that an error should be >> returned with GET parameters (error, error_description...) in the redirected >> url as shown in example. >> But in case of invalid redirection url or unknown client_id (which makes >> validation of redirection url impossible), what http code should I return ? >> 500 ? 400 ? What should be the format of the error message ? Json ? >> plaintext ? like a POST body ? >> >> I'm certainly misunderstanding OAuth spec, but I would appreciate any help. >> Thanks. >> Best regards, >> Jérôme >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
