I'd love to give it a try, but the permissions list in the auth dialog is crazy. Including: "See and download your organisation's G Suite directory", "permanently delete all the calendars that you can access using Google Calendar", "permanently delete your contacts".
I am reasonably sure they need (maybe _need_ here is too-strong a word) those permissions in order to perform certain operations on my calendar, but it just seems so scary to give another company that level of control over my Google account.
I do wish we had more granular permissions across a lot of services out there (e.g. Google, Slack, GitHub), because I can't be alone in not trying something that looks cool because it has the ability to wipe my account out.
This is a perennial issue with Oauth2, but it’s way better than what we had to live with before (pretty much just handing the third party your login).
I get exactly why apps ask for the moon when they’re asking for oauth scopes: to reduce friction. They judge (probably rightly) that if they first ask for a minimal set which accounts for 90% of usage and then later have to ask the user for more permissions later when they want to do a 10% task, that some proportion of users will not “convert” / won’t finish granting the extra permission, even if it means they can’t do the task they were trying to do.
So, they ask for the superset of all permissions their app currently needs (and some permissions that are still just planned functionality), and hope (again, probably rightly) that users won’t really care and will just click through. This creates nightmare issues for infosec teams.
Some sites/apps will ask for the kitchen sink omnibus scope buffet, and then if you click the “oh no thank you, cancel” button on that scopes screen, will actually present you with a reduced set of scopes. They do this without explaining what’s happening or why.
Mobile platforms are getting better about allowing very fine-grained access to permissions. At least on ios, apps that want to access your photos can be given access to only a subset of them. You can pick and choose when to provide location data, etc.
I wish there were an Oauth2 proxy service or something, which let you give apps whatever scopes they ask for, but which would then either fail API requests that use scopes that you’re not actually okay with, or else give valid but not 100% true API responses.
I understand what you’re saying but it seems like the issue here is that the only scope that allows create also allows delete: https://developers.google.com/calendar/api/auth. A proxy service that could reduce the scope of the endpoints you explicitly allow would be helpful here as you mentioned.
It's totally a failure of the platforms. Some of the permissions I've had to request from the Slack API to do the simplest things are insane. Not to mention the "justification" for requesting certain scopes. Like what? You want me to justify a permission that I have no justification for, and I only need it to do this other very unrelated operation.
IIRC: See and download your orgs GSuite directory is required to read contacts in your org's directory, and perm delete calendars is required to edit calendars. https://developers.google.com/calendar/api/auth
It doesn't help that documentation for anything related to Workspace APIs is unbelievably difficult to find, outdated, or both outside of their HTTP REST docs.
This is a great point. I ranted about oauth2 relying parties in my other comment but oauth2 providers certainly don’t make it easy for people writing RPs to figure out what scopes are necessary.
Even worse is that oauth2 doesn’t provide for any capability-based scope limitation, or token attenuation, or anything like that. If I want to be able to give write access to only a single google calendar instead of all of the calendars my account has write access to, the best thing I can do is give write access to a one-off Google account and then oauth2 to that account.
There’s some XACML thing I’ve never heard of before today, no idea if anybody uses it in the wild.
Based on its UI it seems to pose itself as just a more polished version of the entire Google Calendar UI, so I guess if it's trying to be a full replacement it probably needs all the permissions.
I wonder if Google will suddenly EOL half the APIs at some point rendering it unusable though.
It'd be neat if this sort of cross-organization capability granting worked more like e.g. Android permissions. Prompt at the time of the need, not at account creation, and allow the answer to be "Only once".
"App X wants to delete calendar named Y, owned by ACME Corp. [Allow once] [Allow always] [Deny]"
The concept of OAuth Scopes is even more silly when looked at through layman's eyes. If your experience with average humans is, that they will be able to make a judgement calls about wether an app they want to use can reasonably require access to a specific scope, you are not actually dealing with average humans.
Average humans will be at best insecure or indifferent in light of these choices as presented, but certainly not informed. I do think any system asking for these kinds of decisions should at least communication very clearly a recommendation about how to proceed and provide the necessary tools to judge if "permanently delete all calendars" is a reasonable request.
This could maybe be solved with a more thorough (maybe AI automated) review process and JIT OAuth requests (or more frictionless update requests) only when necessary in the app process.
I understand that it's simpler to pawn this off to the user in a roundabout way, but we need to be better and more compassionate with actual users.
I am reasonably sure they need (maybe _need_ here is too-strong a word) those permissions in order to perform certain operations on my calendar, but it just seems so scary to give another company that level of control over my Google account.
I do wish we had more granular permissions across a lot of services out there (e.g. Google, Slack, GitHub), because I can't be alone in not trying something that looks cool because it has the ability to wipe my account out.