Hi all, I'd like to keep things as simple as possible for the end user as well as the consumer, since consumer applications tend to be less concerned with security than service provider applications (and less likely to update their apps).
*1. One time only token exchange* I actually agree with the suggestion to keep the access token endpoint one-time only. This means that you only get one chance to exchange a request token for an access token. At the access token endpoint, if the request token has been authorized, then an access token is granted. If not, the request token is marked as invalid or deleted. This means an attacker would get one shot to exchange the request token (unknown if it's authorized or not) for an access token. Pretty unlikely chance of success and probably not worth the trouble. * 2. No callback request parameter * What about using a callback to guarantee a successful exchange? I'm a fan of eliminating the callback as a request parameter altogether. Allow the consumer to register a callback when they register their application. I've been trying to think of a scenario where a consumer would want a dynamic callback, but I can't think of anything that can't be dealt with (via a redirect) after the OAuth dance is over. This would require a few changes to the spec and would put the burden on the service provider instead of users or consumer apps. Leah --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
