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
