akgood

The AWS Identity and Access Management (IAM) system [1] is perhaps the most comprehensive RBAC deployment I've encountered in a web-based service. It's extremely powerful, extremely flexible, and rather hard to use. AWS is a service designed (primarily) for developer-types, so if they roll out something that requires users to have a relatively strong understanding of security concepts (and to expend some thought and effort to get things right), that's arguably OK.

Google is a different story. People commenting on this thread would appreciate some in-depth manual controls over the resources each Google credential can access, but making this sort of thing accessible/understandable to an average user is a formidable challenge.

They might be able to get part of the way there using a something like a TOFU (Trust on First Use) policy - e.g. after you create an ASP and use it to login over XMPP, that ASP would only be usable for XMPP logins for the remainder of its existence. However, this might still confuse some users or break some assumptions here and there (e.g. what if you have a client application that's designed to do both email and chat?)

Besides all this, I wouldn't be surprised if Google would have to do some major backend re-architecting for this sort of thing to even be possible...

[1] https://aws.amazon.com/iam/

The fix that Google rolled out blocks ASP-based logins from accessing a few highly-sensitive pages on https://accounts.google.com, but otherwise, little has changed. With a quick API request, you can still use an ASP to skip just about any other Google web-based login anywhere on the web. Google might have to completely eliminate their Chrome/Android auto-login feature to actually prevent this sort of thing...

Not true. Read the article :)