I agree with the idea that we need to collect and document some best
practices around the UX of authorization, especially in the case where
it's the end user making the determination. There have been a few chirps
about this in the past, but I haven't seen anyone really stand something
up. The OpenID Foundation has its UI working group which is probably
good place to start.
-- Justin
On 08/06/2012 02:55 AM, Jérôme LELEU wrote:
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 <d.tang...@gmail.com <mailto:d.tang...@gmail.com>>
On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig
<hannes.tschofe...@gmx.net <mailto: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 <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
