Subject: [OAUTH-WG] Option to not prompt the user for authorization

From: Evan Gilbert <[email-masked]>
Date: Wed, 7 Apr 2010 21:20:58 -0700

Authorization servers in the OAuth Web Callback flow and the User Agent flow
should have the option to redirect back with access/refresh tokens without
prompting the user, if the client has already been granted access to the
protected resource.

This is already implied by some of the text (3.4.3.1 "After receiving (or
establishing via other means) an authorization decision from the resource
owner", but is not supported by the example flows.

Suggested changes

3.4.1 Web Callback Flow

   (B) The authorization server authenticates the end user (via
the user-agent) and *MAY prompt* the end user to grant or deny the client's
access request.
   (C) *If authorization server determines the client has access to
protected resource*, the authorization server redirects the user-agent back
to the client to the callback URI provided earlier. The authorization
includes a verification code for the client to use to obtain an access token

3.4.3 User Agent Flow

   (B) The authorization server authenticates the end user (via
the user-agent) and *MAY prompt* the end user to grant or deny the client's
access request.
   (C) *If authorization server determines the client has access to
protected resource*, the authorization server redirects the user-agent to
the redirection URI provided earlier. The redirection URI includes the
access token in the URI fragment.

Also, in cases where the authorization server doesn't prompt the user, we
may want the ability for a client to ask for an immediate decision from the
server instead of prompting the user using a parameter. Suggested changes:

3.4.1.1 Web Callback Flow | Client Requests Authorization
3.4.3.1 User Agent Flow | Client Requests Authorization

(new parameter)
immediate
  OPTIONAL. The parameter value must be set to "true" or "false" (case
sensitive). If set to "true", then the authorization flow MUST check
immediately if the client has access to protected resource and redirect back
with a successful response or "user_denied" error without prompting the
user.

Evan

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 00:22:25 -0700

On 4/7/10 9:20 PM, "Evan Gilbert" <[email-masked]> wrote:

> the user-agent) and MAY prompt the end user to grant or deny the client's
> access request.

How about instead:

(B) The authorization server authenticates the end user (via the user-agent)
and establishes whether the end user grants or denies the client's access
request.

>    (C) If authorization server determines the client has access to protected
> resource, the authorization server redirects the user-agent back to the client
> to the callback URI provided earlier. The authorization includes a
> verification code for the client to use to obtain an access token

I don't think this is needed. The question is whether the user granted
access. My proposed change removes the need to 'prompt' the user, which
makes it possible to establish end user intent without asking again. But as
some point you user must have granted access.
 
> the user-agent) and MAY prompt the end user to grant or deny the client's
> access request.
>    (C) If authorization server determines the client has access to protected
> resource, the authorization server redirects the user-agent to the redirection
> URI provided earlier. The redirection URI includes the access token in the URI
> fragment.

Same.

> Also, in cases where the authorization server doesn't prompt the user, we may
> want the ability for a client to ask for an immediate decision from the server
> instead of prompting the user using a parameter. Suggested changes:
> 
> with a successful response or "user_denied" error without prompting the user.

How about:

immediate:

OPTIONAL. The parameter value must be set to 'true' or 'false' (case
sensitive). If set to 'true', the authorization server MUST NOT prompt the
end user to authenticate or approve access. Instead, the authorization
server attempts to establish the end user's identity via other means (e.g.
Browser  cookies) and checks if the end user has previously approved an
identical access  request by the same client and if that access grant is
still active. If the authorization server does not support an immediate
check or if it is unable to establish the end user's identity or approval
status, it MUST deny the request without prompting the end user. Defaults to
'no' is omitted.

Also, is it safe to add to the user-agent flow since the client isn't the
same entity as a web server, but another installation? I think it is but
want to ask before I add it there.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 8 Apr 2010 21:17:22 -0700

> and establishes whether the end user grants or denies the client's access

The end user doesn't always control the resource grant decision (as an
example, a domain admin may grant access for users).

Maybe "establishes whether the client has been granted access to protected
resource"?

However, looking at all of the variants, think these new phrasings leave
some ambiguity. Ideally this will be clear to the reader that the user agent
may return immediately or may interact with the end user.

> some point you user must have granted access.

Per note above, think it's slightly limiting to say the user must have
granted access.

> may

This is better. Couple of requested modifications:
- Same point on whether the user has to grant access. Possibly change:
"checks if the end user has previously approved an
identical access  request by the same client and if that access grant is
still active" to
"checks if the client is authorized to access protected resource"
- Defaults to 'no' if omitted -> Defaults to 'false' if omitted

> want to ask before I add it there.

Not sure I followed this question - could you provide more details?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 23:50:57 -0700

> example, a domain admin may grant access for users). 

No. Bu definition the end user (which is a specialized resource owner) is
the only party allowed to grant authorization. Whoever grants authorization
is the resource owner.

> However, looking at all of the variants, think these new phrasings leave some
> ambiguity. Ideally this will be clear to the reader that the user agent may
> return immediately or may interact with the end user.

The spec should make the flow simple to understand to a first-time/casual
reader, and the basic scenario is where the user is prompted. As long as it
doesn't prevent other specializations, it should not become harder to follow
and more cryptic. It cannot tell a story without making some basic
assumptions.

> Per note above, think it's slightly limiting to say the user must have granted
> access.

In OAuth the resource owner controls the decision. If you want someone else
to control the decision, they are the resource owner. That's the model.

> "checks if the client is authorized to access protected resource"

I prefer the current text.

> - Defaults to 'no' if omitted -> Defaults to 'false' if omitted

Thanks.

> Not sure I followed this question - could you provide more details?

There is no client secret because the client isn't a single instance but
something running on many separate computers. So when the server has to
check if the client has access, its really just limited to checking if the
logged in user approved that client identifier before. This breaks as soon
as the user is tricked to follow a link using a client identifier he already
approved.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 9 Apr 2010 08:29:36 -0700

> the only party allowed to grant authorization. Whoever grants authorization

 Makes sense. To capture this, think we need to change
 "establishes whether the end user grants or denies" -> "establishes whether
the resource owner grants or denies".

> some

The basic scenario for the User Agent profile involves automatic redirects.
The access tokens are short lived, and the profile is mostly useless unless
authentication services support and clients use these redirects.

Also note that I still think removing ambiguity is good. This doesn't have
to be at odds with making it easy for the first-time/casual reader.

> granted

(per previous note, we should then change to say "resource owner" not "end
user")

> I prefer the current text.

"end user has previously approved" -> "resource owner has previously
approved"

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 11:02:03 -0700

> the resource owner grants or denies".

In this flow the resource owner is an end user. I have a problem with your
premise. No one should be granting client access to end user resources,
except for the end user. If this is a case where the end user is accessing
resources owned by someone else (the domain admin), the entire story is
broken (it has both a resource owner and end user who are different).

> authentication services support and clients use these redirects.

As soon as some security-minded folks review the proposal to add immediate
support for the user-agent flow, I'll add it in (I don't have objections).

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Fri, 9 Apr 2010 13:58:25 -0700

On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> >>> On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav <
> [email-masked]>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Authorization servers in the OAuth Web Callback flow and the User
> Agent
> >>>>> flow

This use case mostly just works & we're excited about using the OAuth flow
this way. The premise that "no one should be granting client access to end
user resources,
except for the end user" is incorrect - we already support variant of this
today at Google and it's a requirement for almost all enterprise use cases.

I had assumed that this is why the definition of resource owner is "An
entity capable of granting access to a protected resource" - this wording
covers both cases.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 22:08:31 -0700

> today at Google and it's a requirement for almost all enterprise use cases.

The user delegation flows are about an end user (specifically a human
resource owner) actively approving access. The scenario you are describing
is where the end user is actually something else, it is not a resource owner
but just "an entity capable of authenticating with the authorization
server".

In your scenario (which can use the same technical flow, but is a different
construct), the resource owner (domain admin) grants client access before
the flow begins, the client then sends an end user to the authorization
server to authenticate (often blindly, and nothing else), then the
authorization server acting based on the resource owner's grant, provide
access.

Your resource owner is by definition not the end user, and your end user is
by definition on a 'human resource owner'. So while the HTTP calls still
work, the prose is wrong.

If you feel that the current prose *prevents* you from implementing it as
required by your use case (which I don't think it does), we can add a
paragraph noting the special case where the resource owner and end user are
split.

EHL

> I had assumed that this is why the definition of resource owner is "An entity
> capable of granting access to a protected resource" - this wording covers both
> cases.

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 12 Apr 2010 10:13:39 -0700

On Fri, Apr 9, 2010 at 10:08 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> >>> On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav <
> [email-masked]>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>>>> This is already implied by some of the text (3.4.3.1 "After
> receiving
> >>>>>>> (or

Not sure I parsed this. The only significant difference I'm suggesting to
covert is to change "end user" to "resource owner", which I think is only
additive in the use cases it supports.

> paragraph noting the special case where the resource owner and end user are

The current prose doesn't allow for the domain user granting access. This
limitation is one that authorization services in practice will likely
ignore, but I'd rather the spec state more explicitly allow domain-admin
granted access as an option.

It's a really good thing that the spec would require such minimal changes to
support the domain admin granted use case, and I think we can find
terminology that supports both without confusing it for the end-user
granting use case.

Note that this flow is really important if you want OAuth 2.0 to be useful
and relevant in the enterprise - end-users typically won't be given direct
authority to share their data with 3rd parties.

> entity