Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow only requesting the oauth scopes that an app needs #440

Open
TheBeruriahIncident opened this issue Jun 11, 2024 · 3 comments
Open

Comments

@TheBeruriahIncident
Copy link

Is your feature request related to a problem you're having? Please describe.
My app needs to write new files to Google Drive, and it needs nothing else. As such, the only scope I request is https://www.googleapis.com/auth/drive.file. However, the login screen suggests that the app will be much more invasive than it is:
image

It appears that additional scopes beyond what the consuming app requests are always requested:
https://github.com/google/GoogleSignIn-iOS/blob/main/GoogleSignIn/Sources/GIDSignInInternalOptions.m#L56
https://github.com/google/GoogleSignIn-iOS/blob/main/GoogleSignIn/Sources/GIDScopes.m#L58
Specifically it looks like the email and profile scopes are always added.

My assumption is that those additional scopes are unnecessary for basic usage, but please tell me if I am incorrect.

As an additional downside, requesting extraneous scopes makes implementing Google's new granular permissions more messy and complicated.

Describe the solution you'd like
In the spirit of the principle of least privilege, it should be possible to use Google SignIn without extraneous scopes added. To do this in a backwards compatible way, the current behavior should remain the default, but it should be possible to set a flag to avoid scopes being added.

This seems like a very small change.

Describe alternatives you've considered
First, it's possible that those other scopes are necessary for all Google API usage. However, the fact that granular permissions allows rejecting them, that seems false.

Second, it's possible that consumers of Google SignIn just live with requesting extra scopes. However, that makes their apps look more invasive than they need, and thus sketchy. Further, it means that developers need to unnecessarily handle the more complicated granular permission case where you request many scopes.

Additional context
I'm happy to contribute this feature if it would be accepted.

@TheBeruriahIncident TheBeruriahIncident added enhancement New feature or request triage Issues that need to be triaged labels Jun 11, 2024
@TheBeruriahIncident TheBeruriahIncident changed the title Allow only requesting the oauth scopes that an app need Allow only requesting the oauth scopes that an app needs Jun 11, 2024
@TheBeruriahIncident
Copy link
Author

Ah, it looks like this worked as we would like in 5.0.0 and switched to the more invasive behavior by 5.0.2, which is why we didn't notice this issue in older versions. So, this is functionally a user-experience regression.

@mdmathias
Copy link
Collaborator

I cannot speak to why this behavior changed between v5.0.0 and v5.0.2. My guess is that it had something to do with the idea that GSI is primarily focused on providing features associated with signing in, and providing, a user. The profile scope comprises basic information for the currently signed in user. I suspect the email was considered integral as well.

To be honest, I do not think it is likely that we change the current automatic scope requests for profile and email. It is definitely not going to be something we do in the next release (v7.2.0).

I can leave this issue open for a little bit to see if others are interested in a change. I could imagine an API where developers can modify the automatic scopes: i) the default where email and profile are requested, and ii) the modification where developers ask for some subset of those.

@mdmathias mdmathias removed enhancement New feature or request triage Issues that need to be triaged labels Jun 11, 2024
@TheBeruriahIncident
Copy link
Author

Gotcha, thanks so much for your thoughts! That makes sense, but do you know if there is a suggested alternative route for developers who are only using APIs like Drive or Sheets? My understanding is that Google recommends this tool for that use case, so it seems good to either support that use case well or for Google to recommend a different tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants