On 4/7/10 9:20 PM, "Evan Gilbert" <[email protected]> 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.
> (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.
> 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.
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
