Repository navigation
Request additional scopes with signIn #23
Description
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
Activity
ivopintodasilva commentedon Jul 14, 2021
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 commentedon 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 commentedon Jul 15, 2021
Thanks @petea for the explanation.
petea commentedon Jul 19, 2021
Reopening for discussion.
[-]SignIn with Scope directly [/-][+]Request additional scopes with `signIn`[/+]AntonKozlovskyi commentedon Jul 20, 2021
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 inquestion, 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 commentedon 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 commentedon Jul 20, 2021
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 commentedon Jul 20, 2021
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 commentedon Jul 27, 2021
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 commentedon Aug 4, 2021
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 commentedon Aug 5, 2021
@cpboyd note that basic profile scopes (email, profile, openid) are granted with the
signInflow, an additionaladdScopesflow is not required unless you need scopes beyond basic profile such as Contacts, Drive, Calendar, etc.14 remaining items
cpboyd commentedon 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 commentedon Nov 24, 2021
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 commentedon Nov 25, 2021
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 commentedon Nov 29, 2021
We're also hitting this problem, would appreciate the PR getting merged and a new release!
nickprokopievds commentedon Dec 7, 2021
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 commentedon Feb 25, 2022
Jeez... here we are in 2022. 😓
jkichline commentedon Feb 28, 2022
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 commentedon Mar 1, 2022
@jkichline Would you kindly fork this project so we can use SPM? 🙏🏻 thanks
petea commentedon 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 commentedon May 11, 2022
Is there any update on this issue? Is it available?
petea commentedon May 11, 2022
@rldaulton the 6.2.0 release, which will address this issue, should be ready within a week.
petea commentedon May 19, 2022
Google Sign-In 6.2 has been released.