On 4/8/10 9:17 PM, "Evan Gilbert" <uid...@google.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav <e...@hueniverse.com>
> wrote:
>>
>>
>>
>> On 4/7/10 9:20 PM, "Evan Gilbert" <uid...@google.com> wrote:
>>
>>> 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.
>>
>> 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.
>
> The end user doesn't always control the resource grant decision (as an
> 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.
> 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.
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.
>>
>>> (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.
>
> 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.
>>
>>> 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.
>>
>> 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:
>>>
>>> 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.
>>
>> 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.
>
> 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"
I prefer the current text.
> - Defaults to 'no' if omitted -> Defaults to 'false' if omitted
Thanks.
>
>>
>> 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.
>
> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
