A few comments on the Web Server and Web Client flow from the draft
2.0 spec<http://github.com/theRazorBlade/draft-ietf-oauth/>
.

Evan

----

2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
In both flows, the authorization server should be able redirect back to the
callback URI without interacting directly with the resource owner if access
has already been approved.  This is not ruled out in the current language
but it could be made cleaner.

Suggested rewording - change

"After receiving an authorization decision from the resource owner, the
server redirects the resource owner to the callback URI."

  to

"If the client is already approved or denied for access to the protected
resource, the authorization service MAY redirect the resource owner to the
callback URI immediately. If not, the authorization service SHOULD ask the
resource owner for an authorization decision and after receiving the
decision redirect the resource owner to the callback URI."

----

2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
We should have an OPTIONAL username parameter:
username
  The resource owner's username. The authorization server MUST only send
back refresh tokens or access tokens for this user.

This is useful for clients where a user is already logged into a 3rd party
web site with a specific account, and the client wants the authorization to
match the specific user.

----

2.4.2 Web Client Flow
Sending an access token as a query parameter is dangerous from a security
perspective - these tokens are leaked via referrers and server logs. In
previous WRAP discussions, it was felt that we should have a strong
recommendation to use the URL fragment.

Suggested wording:
Client SHOULD send a callback URI with a query fragment, and authorization
server MAY reject callback URLs without a fragment for security reasons.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to