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

Request additional scopes with signIn #23

Closed
floriangbh opened this issue Jul 14, 2021 · 37 comments
Closed

Request additional scopes with signIn #23

floriangbh opened this issue Jul 14, 2021 · 37 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@floriangbh
Copy link

Hello,

Since the 6.0.0 it looks like isn't anymore possible to SignIn with scopes. The only way I'v found is :

  • firstly call signInWithConfiguration:presentingViewController:callback:
  • then call addScopes:presentingViewController:callback:

In my case, I need to connect my user to their Youtube account. It results in two" sign in" in a row, which can be weird for some users.

Is there a way to make one sign in with scope or this is a volunteer behavior?

Btw, thanks for the SPM and M1 compatibility!

Thanks
Florian

@ivopintodasilva
Copy link

I'm facing the exact same problem.

Previously my login flow (login + grant scopes) was contained in a single web view step. Now we need to show one web view for the sign in and another for granting permissions which feels less convenient.

And thanks a lot for SPM and Apple Silicon support! It's awesome 😃

@petea
Copy link
Contributor

petea commented Jul 14, 2021

You are correct, with the 6.0.0 release we're requesting only the basic profile scopes (email, profile, openid) in the user's initial sign-in flow. If you require an additional scope, this will need to happen via addScopes:presentingViewController:callback: sometime after the sign-in flow has been completed. In keeping with the incremental authorization pattern, we recommend that any additional scope requests happen right before the scope is to be used and with context provided to the user as to why they might want to grant access.

@floriangbh
Copy link
Author

Thanks @petea for the explanation.

@petea
Copy link
Contributor

petea commented Jul 19, 2021

Reopening for discussion.

@petea petea reopened this Jul 19, 2021
@petea petea changed the title SignIn with Scope directly Request additional scopes with signIn Jul 19, 2021
@AntonKozlovskyi
Copy link
Contributor

Hi @petea. Very often we need to get all the scopes in time of sign in(or just after), and in this case it's very inconvenient to user to see Are you sure you want to sign in question, make a login and after that see this message again. Some of users could just cancel second one or decide that it's an issue. And in cases when user already gave this permissions( like when he used to use application, removed it and now installed again), after second question it just showing WebView and hide it immediately. It's working, but not very nice looking.

Other approach is just add possibility to hide 2nd popup with sign in question for cases when adding scopes going just after sign in.

@mamilov
Copy link

mamilov commented Jul 20, 2021

Hi @petea. In our App, we have a use case that suffers from this decision. Our users are able to link their calendars (multiple options available) and he only needs sign-in to when we need his calendar consent. This now leads us to having to move the user through two sign-ins (from the eyes of the user) which is bad UX.
We understand the decision of only asking for consent if needed, but we also only want him to login when he wants to link his calendar.
It would be great if it would be possible to combine those two requests into one sign-in-flow again.

@ivopintodasilva
Copy link

Hello @petea 👋 I have the same flow as @mamilov.
As soon as users sign in or register, the first screen we show is filled with information from Google Calendar.
By not being possible to sign in and add the calendar scope at the same time, we are forced to show two sign-in sheets just for the user to be able to get to our first authenticated screen 😔
Previously this was done in one step which was much more user friendly for our purposes.

@jkichline
Copy link

This is not a good call. I understand your desire to sign in and then prompt for scope at a later time as more functionality is required. However in our app, this just creates a very poor user experience. That's because we have Google Drive integration and that's all we need. So basically the user signs in and then immediately has to click a prompt again to open a dialog that appears to close immediately to provide the additional scope. Why? What was wrong with the previous method? This appears to be a poor decision on Google's behalf to force developers to use their product in a way that does not make sense. We require the ability to sign in with an initial scope. Period.

@ivopintodasilva
Copy link

Hi @petea 👋
Any update on this matter? It seems like this change is heavily affecting the UX of a fair amount of apps...

@Haibo-Zhou
Copy link

I get this same issue, I think the repeated web view will confuse the user. Because user don't know or don't care it is an addScope of whatever. But they do see two web view for grant permission appearing in a row, which is really weird!

I agree that we could add scope when sign in like before.

@petea
Copy link
Contributor

petea commented Aug 5, 2021

@cpboyd note that basic profile scopes (email, profile, openid) are granted with the signIn flow, an additional addScopes flow is not required unless you need scopes beyond basic profile such as Contacts, Drive, Calendar, etc.

@cpboyd
Copy link

cpboyd commented Aug 5, 2021

@petea Thanks for clarifying! I'm not currently using any other scopes, but my app depends on the Flutter plugin.

Would it be possible to build the extra scope flow into the existing WebView pop-up? i.e. somehow give users the ability to opt-out of specific scopes?

It seems like that might be nice even if not requesting at log-in, since a user might want to grant permission to Drive but not Contacts.

@rpassis
Copy link

rpassis commented Aug 30, 2021

FWIW since this library is now open source you can pretty trivially expose the interfaces from GoogleSignIn_Private.h and GIDSignInInternalOptions.h to achieve the single step authentication with scopes flow.

The implementation is already there (and is actually the same one used by the public signIn method) but just not exposed publicly.

let viewController = UIViewController()
let configuration = GIDConfiguration(clientID: "clientID", serverClientID: "serverID")
let options = GIDSignInInternalOptions.defaultOptions(
    with: configuration,
    presenting: viewController,
    loginHint: nil
) { user, error in

}
options.scopes = ["A", "B", "C"]
GIDSignIn.sharedInstance.signIn(with: options)

For the changes needed, see this commit

@dsharma
Copy link

dsharma commented Oct 3, 2021

FWIW since this library is now open source you can pretty trivially expose the interfaces from GoogleSignIn_Private.h and GIDSignInInternalOptions.h to achieve the single step authentication with scopes flow.

The implementation is already there (and is actually the same one used by the public signIn method) but just not exposed publicly.

let viewController = UIViewController()
let configuration = GIDConfiguration(clientID: "clientID", serverClientID: "serverID")
let options = GIDSignInInternalOptions.defaultOptions(
    with: configuration,
    presenting: viewController,
    loginHint: nil
) { user, error in

}
options.scopes = ["A", "B", "C"]
GIDSignIn.sharedInstance.signIn(with: options)

For the changes needed, see this commit

I see the recent version 6.0.2 has different code structure than your commit!

@crspybits
Copy link

I agree too, that in my app this makes for a UX that looks odd. What are users to understand from this "second sign in" requirement? Here's the way it looks in my app:

Example.for.work.mov

As remarked, it's not that hard to change the repo in your own fork to work around this. That will put additional overhead on devs using this repo though, when one wants to integrates changes from the main repo though.

@floriangbh
Copy link
Author

Hello @petea

Reopening for discussion.

The discussion is now opened for 3 months, what's the result?
We will see any change in the official repo? Or do we need to fork?

Thanks

@dsharma
Copy link

dsharma commented Oct 5, 2021

I need way to workaround, it's a very dumb decision to have two step authentication like this.

@crspybits
Copy link

You can use the fork/PR here to workaround. I have a fork too with similar workaround..

Also, IMO, judging decisions as dumb is not Being considerate, kind, constructive, and helpful. (see https://github.com/google/.github/blob/76351dccba796e06868acdaeadfae58f11622e7a/CODE_OF_CONDUCT.md).

@wreppun
Copy link

wreppun commented Oct 5, 2021

To me the most confusing thing about this process is that, underneath the hood, google implements oauth. So:

  1. Why would you mess with the extremely well-known oauth specs/expectations by limiting the scopes an application can initially request? IMO, this definitely violates the principle of least astonishment.
  2. Why would you change the process only for the consumers of this particular library? Anyone can work around it by implementing the oauth client protocol themselves, or simply forking the library (as others have already done).

This is definitely a head scratcher for me. I understand that applications can eff with users by requesting all kinds of extra permissions along with the basic permissions needed to sign in. But this doesn't change anything -- bad actors can trivially work around it -- and I'm curious how this was sold as a feature.

@dsharma
Copy link

dsharma commented Oct 6, 2021 via email

@dazwin
Copy link

dazwin commented Oct 6, 2021

Our users may be signing in to Google as a secondary account immediately before we use of one of the requested scopes - the flow is following incremental authorization. Requiring a double sign-in creates a very bad user experience.

Removing functionality, especially changes done with tacit assumption that developers don't know any better, should be done conservatively and with much feedback. Please reverse this decision.

@crspybits
Copy link

@dsharma To help you I'd need more details. I haven't used the sample. Why do you still need to grant additional scopes?

@dsharma
Copy link

dsharma commented Oct 12, 2021 via email

@nathandud
Copy link

nathandud commented Oct 13, 2021

Not all users of our app authenticate with Google at sign-in, but later add Google Photos as a source for creating photo books. After upgrading to 6.0.2, we are pigeon-holed into back-to-back requests causing double UIAlert views and presented SFSafariView controllers. This seriously degrades the user experience. Requesting scopes at sign-in seems like a very legitimate use-case for apps like ours that don't rely on Google for their primary auth mechanism. Please consider re-introducing this capability in a future release.

@dineshflock
Copy link

dineshflock commented Nov 11, 2021

You are correct, with the 6.0.0 release we're requesting only the basic profile scopes (email, profile, openid) in the user's initial sign-in flow. If you require an additional scope, this will need to happen via addScopes:presentingViewController:callback: sometime after the sign-in flow has been completed. In keeping with the incremental authorization pattern, we recommend that any additional scope requests happen right before the scope is to be used and with context provided to the user as to why they might want to grant access.

I believe the need for this changes was to provide incremental authorisation ie

It is considered a best user-experience practice to request authorization for resources at the time you need them.

So if my app needs sign in with scope, and for us we know that the right point to ask for scope is at google sign in, then showing this unusual flow to my customers, just to provide 'a best user-experience' does not make sense.

Developers should be allowed to choose what's best point to get scopes. And if we feel the best point is at sign-in then we should be allowed to have sign in + scopes in one go.
This should be a recommendation but not enforcement. It seems like it is assumed that devs will never need sign in and scopes at same time.
For now we are rolling back to latest v5.x.x

@cpboyd
Copy link

cpboyd commented Nov 13, 2021

Even Flutter, Google's own cross-platform app development platform is still avoiding v6 due to this specific issue:
flutter/flutter#86436

Clearly having developers avoid upgrading the SDK (potentially adding security vulnerabilities to countless apps) isn't the intention of this change.
If developers can easily avoid incremental authorization with v5, then what's the ultimate point of the change?

Shouldn't the proper course of action have been to give advance notice of the change with proper deprecation and a cut-off deadline?

@jerbob92
Copy link

I'm the maintainer of https://github.com/klippa-app/nativescript-login and I'm holding off the upgrade due to this issue.
It made sense to add this addScopes method to add extra scopes later on, if you need extra data from the user in a later process in the app, so that's perfectly fine.

However, it doesn't make a lot of sense to remove the scope parameter in the initial flow, as a lot of apps need extra scopes for their app to work at all, and the login flow is perfectly able to show the information about these scopes. On this principle my plugin is built and the only way now is to show 2 logins modals, which degrades the plugin UI, so I'm holding it off for now.

@flobauer
Copy link

Can this PR be merged? #67
The necessity for user experience is absolutely given for apps who only login to get a specific API working!

@garrettm
Copy link

We're also hitting this problem, would appreciate the PR getting merged and a new release!

@nickprokopievds
Copy link

Is there a chance this change can be merged any time soon? This is the only reason we are still using the old library version :-/

@brunomunizaf
Copy link

Jeez... here we are in 2022. 😓

@jkichline
Copy link

Hey everyone. I got sick of Google's eternally beta software. It seems that this stupid two step process also caused my users to not actually being signed in correctly and caused non-authenticated daily usage limits. So I wrote this addition for Objective-C that adds the single sign-in method with scopes. Enjoy.
GIDSignIn+Scopes.zip

@brunomunizaf
Copy link

@jkichline Would you kindly fork this project so we can use SPM? 🙏🏻 thanks

@petea
Copy link
Contributor

petea commented Mar 7, 2022

Thanks to everyone for sharing your concerns and specific examples.

The incremental authorization pattern continues to be the recommended way to handle authorization after authentication when requesting additional scopes for specific features of your integration.

However, we understand that for certain use cases this incremental authorization approach has led to a degraded user experience with the flow requesting authorization of an additional scope being seen immediately after the user has just completed the authentication flow.

In our 6.2 release we will return the ability to request additional scopes as part of the sign-in moment for apps that require this for their core functionality. This release will be made available in the coming weeks.

@rldaulton
Copy link

Is there any update on this issue? Is it available?

@petea
Copy link
Contributor

petea commented May 11, 2022

@rldaulton the 6.2.0 release, which will address this issue, should be ready within a week.

@petea
Copy link
Contributor

petea commented May 19, 2022

Google Sign-In 6.2 has been released.

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

No branches or pull requests