Request additional scopes with signIn

[floriangbh]

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]

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]

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]

Thanks @petea for the explanation.

[petea]

Reopening for discussion.

[AntonKozlovskyi]

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]

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]

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]

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]

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]

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]

@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]

@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]

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]

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]

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]

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]

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

[crspybits]

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]

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]

Christopher, I tried your fork but still in the sample I need to grant additional scopes.

…

On Tue, Oct 5, 2021 at 4:28 PM Christopher Prince ***@***.***> wrote: You can use the fork/PR here to workaround. I have a fork too with similar workaround. <https://github.com/crspybits/GoogleSignIn-iOS>. 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 ). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF3UPXWZUWC2SFLY343RLUFLVPFANCNFSM5ALD7H7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dazwin]

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]

@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]

Ok it's working. Thank you for the help.

…

On Thu, Oct 7, 2021 at 7:02 AM Christopher Prince ***@***.***> wrote: @dsharma <https://github.com/dsharma> To help you I'd need more details. I haven't used the sample. Why do you still need to grant additional scopes? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF3UONQLRS6V5KIT72BE3UFUEUTANCNFSM5ALD7H7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[nathandud]

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]

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]

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]

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]

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]

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

[nickprokopievds]

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]

Jeez... here we are in 2022. 😓

[jkichline]

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]

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

[petea]

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]

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

[petea]

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

[petea]

Google Sign-In 6.2 has been released.