Subject: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?

From: Jérôme LELEU <[email-masked]>
Date: Fri, 3 Aug 2012 09:07:17 +0200

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

---

From: Doug Tangren <[email-masked]>
Date: Fri, 3 Aug 2012 08:36:11 -0400

> What are the security concerns about not having such "Allow / disallow"

Obtaining access to a user's data without their consent?

---

From: Jérôme LELEU <[email-masked]>
Date: Fri, 3 Aug 2012 15:23:10 +0200

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 <[email-masked]>

---

From: Håvard Geithus <[email-masked]>
Date: Fri, 3 Aug 2012 15:42:19 +0200

If you look at Google's
API<https://developers.google.com/accounts/docs/OAuth2WebServer>,
they have a parameter named approval_prompt which can be "force" or "auto":

Description:
*Indicates if the user should be re-prompted for consent. The default is
auto, so a given user should only see the consent page for a given set of
scopes the first time through the sequence. If the value is force, then the
user sees a consent page even if they have previously given consent to your
application for a given set of scopes.*
*
*
I guess that's one way to solve it :)

On Fri, Aug 3, 2012 at 3:23 PM, Jérôme LELEU <[email-masked]> wrote:

> 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...
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 3 Aug 2012 07:21:08 -0700

In OAuth 2 the  A is Authorization, not Authentication.

Not all flows support user interaction, so it can't be a MUST present dialog, as that may not be possible.

For flows such as code and implicit the Authorization server should present the user with a choice of allowing the requested scopes.

Depending on the protected resource and client the Authorization server may not present each scope individually, it would depend on the API being protected.

Your question seems to presume some sort of federated login like Facebook Connect, or openID Connect.   The specifics of using OAuth for federated login are out of scope for the core OAuth spec.

In those cases you need to inform the user and involve extensions to OAuth for security and dealing with login sessions.

You can look at openID Connect or Googles documentation on using OAuth for SSO to get more information on that use-case.

On 2012-08-03, at 6:23 AM, Jérôme LELEU wrote:

> 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...
> 
> What are the security concerns about not having such "Allow / disallow" screen ?
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 3 Aug 2012 10:47:43 -0400

The approval screen is a detail of the UX that the protocol itself 
doesn't address, since there are several instances where an approval 
screen does and does not make sense.

If you're doing a "trust on first use" (TOFU) scenario where the 
resource owner is the same as the end user (remember, they may be 
different entities entirely!), then the approval screen is very 
important. This is the classical OAuth use case, and one of the primary 
novel things that it allows for which other protocols don't. Since most 
of the publicly-facing deployments of OAuth are in this kind of world, 
where you're using the end user to bridge trusted security boundaries 
via OAuth, then you see a lot of this.

If your end user and resource owner are different entities, then the 
person sitting at the browser might not actually have a choice about 
whether to allow access. In this case, it doesn't make any sense to ask 
them because the decision is being made by policy, or by circumstances 
around the request. It does still make sense to do a three-legged OAuth 
in this flow, because you can then bind the context of the user having 
authenticated to the AS in the front channel with the client having 
authenticated to the AS in the back channel. This separating and 
re-binding gives you three legs in an authorization triangle, which is a 
very powerful and secure pattern to follow. We're starting to see things 
like this in the enterprise world around OAuth. Instead of using an 
all-powerful tight binding credential between systems, you've got a 
whitelisted OAuth client. As far as the client knows, it's doing vanilla 
OAuth and the world is all as it should be. This is a very good (and 
somewhat novel) thing for enterprise systems.

But even in the TOFU scenario, it's important to let the user say 
"remember this decision in the future and don't bug me about it". In 
this case, the server remembers the authorization grant decision that 
was previously made by the resource owner and doesn't prompt the user. 
Most OpenID 2.0 setups do this already, and some OAuth setups do as 
well. I think Google does this, I know we're building it in to our 
projects, and I think we'll see more of this functionality going forward.

-- Justin

On 08/03/2012 03: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.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 3 Aug 2012 12:19:09 -0700

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. 

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.
>

---

From: Doug Tangren <[email-masked]>
Date: Fri, 3 Aug 2012 15:23:02 -0400

On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig <[email-masked]
> wrote:

> 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.
>
> 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).

---

From: Jérôme LELEU <[email-masked]>
Date: Mon, 6 Aug 2012 08:55:35 +0200

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

>
>
> On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig <
> [email-masked]> wrote:
>
>> Hi Jerome,
>>
> This is not an oauth issue but an application UX issue dating back to
> oauth 1.
>
>> 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.
>> >

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Aug 2012 11:06:18 -0400

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:
> 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) ?
> 2012/8/3 Doug Tangren <[email-masked] <mailto:[email-masked]>>
>
>
>
>     On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Jerome,
>
>         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.
>
>         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
>
>         > 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.
>         >
>         > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Paul Madsen <[email-masked]>
Date: Tue, 07 Aug 2012 09:07:04 -0400

there are legitimate (non consumer centric) applications of OAuth where 
such explicit consent gathering is not necessary

On 8/3/12 9:23 AM, Jérôme LELEU wrote:
> their consent, they previously clicked on the "Authenticate at the 
> OAuth provider" link...
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Tue, 7 Aug 2012 13:21:00 +0000

Hi Jérôme,

I am one of those non-consumer use cases where explicit consent is not part of our envisioned OAuth flow.  The resource servers that we create and sell to our customers are owned by the customer's IT department, so when a user (employee) authenticates to the AS, it is the enterprise policy rules that determine whether or not the user is authorized to obtain an access-token or not.  The confusion is that in classic OAuth the end-user and resource owner are often the same, but in other cases (including mine) this is not the case.  Hope that helps.

-adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Madsen
Sent: Tuesday, August 07, 2012 8:07 AM
To: Jérôme LELEU
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ?

there are legitimate (non consumer centric) applications of OAuth where such explicit consent gathering is not necessary

Thanks,
Jérôme

2012/8/3 Doug Tangren <[email-masked]<mailto:[email-masked]>>

OAuth mailing list

[email-masked]<mailto:[email-masked]>