[OAUTH-WG] Authorization request errors
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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization request errors
Hi, Thanks for your replies. The possible security breach is clear to me : I would never redirect to a redirect_uri url if I didn't validate the client_id and if it didn't match the associated registered redirection url. My understanding of Torsten message is that the error page is in a free HTML format for end user with HTTP code 200 (status : OK). I think the spec could be more precise on this point. Thanks. Best regards, Jérôme 2012/7/4 John Bradley > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > ___ > 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
[OAUTH-WG] Is "Allow / disallow" screen mandatory ?
Hi, In the OAuth 2.0 spec, I don't see any mention of the "Allow / disallow" screen (just after the user is logged in). However, most of the OAuth providers I know (Facebook, Google, Twitter...) have such a "allow / disallow" screen. Did I miss something in the spec ? What are the security concerns about not having such "Allow / disallow" screen ? Thanks. Best regards, Jérôme ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?
Said like that, I feel totally stupid... but it's not totally without their consent, they previously clicked on the "Authenticate at the OAuth provider" link... I understand that it's mandatory. Thanks, Jérôme 2012/8/3 Doug Tangren > > What are the security concerns about not having such "Allow / disallow" >> screen ? >> > > Obtaining access to a user's data without their consent? > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?
Hi, Thank you all for your answers. I read section 1.3.1 : "the authorization server authenticates the resource owner and obtains authorization", the "obtains authorization" implies the confirmation screen I talked about. But it's not only about UI. There are some behaviour issues remaining : is there a "disallow" button ? where does it point at ? when should this screen appear (every time, just the first time and why) ? This confirmation screen deserves more explanations. Thanks. Best regards, Jérôme 2012/8/3 Doug Tangren > > > On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig < > hannes.tschofe...@gmx.net> wrote: > >> Hi Jerome, >> >> you raise a good and important point. >> >> A core part of the OAuth specification is to obtain the consent of the >> resource owner. If you look at Section 1.3 of >> http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the different >> authorization grants that are supported. Except for the client credential >> authorization grant every other grant type requires a protocol exchange to >> obtain the permission from the resource owner. >> >> The threats document discusses the importance of the consent mechanism in >> more detail. >> >> However, the actual screen (and the importance of the UI representation) >> is not standardized. Most standardization organizations do not standardize >> the look-and-feel of the actual permission screen. Having said that I >> believe it is a very important aspect of every identity management protocol >> and there is research available. Maybe someone should put a page with a few >> links together to illustrate the current state of the art and the best >> current practice. >> >> > This is not an oauth issue but an application UX issue dating back to > oauth 1. > > Many service providers offer an "authorize" endpoint that always asks for > authorization (safer for the user but less convenient) and "authenticate" > endpoint that skips authorization if the user previously authorized the app > (more convenient but less safe). > > > > > >> Ciao >> Hannes >> >> On Aug 3, 2012, at 12:07 AM, Jérôme LELEU wrote: >> >> > Hi, >> > >> > In the OAuth 2.0 spec, I don't see any mention of the "Allow / >> disallow" screen (just after the user is logged in). However, most of the >> OAuth providers I know (Facebook, Google, Twitter...) have such a "allow / >> disallow" screen. >> > >> > Did I miss something in the spec ? >> > >> > What are the security concerns about not having such "Allow / disallow" >> screen ? >> > >> > Thanks. >> > Best regards, >> > Jérôme >> > >> > ___ >> > 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 >> > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Access token timeout
Hi, I might be misunderstanding the OAuth 2.0 spec (part 5.1, "expires_in" property), but I understand that the timeout of the access token is a hard one (amount of time between creation and expiration). Am I right ? Can we have a multiple use timeout ? A sliding window timeout ? Or a combination of all ? Thanks. Best regards, Jérôme ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
