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). 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. > > (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. > > > 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" - Defaults to 'no' if omitted -> Defaults to 'false' if 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. > Not sure I followed this question - could you provide more details? > > EHL > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
