⋮    ⋮  

Google Announces New Sign-in Rules, Here’s What Will Change For Third-Party Apps

Author Photo
Apr 4, 2017
15Shares
Submit

We reported earlier about how Google is bringing material design to its web sign-in pages. Now, the search engine giant has rolled out an update for sign-in page rules, which must be abided by the third-party Single Sign-On (SSO) providers.

The new policies will be effective from April 5, 2017, and it will add another security blanket for the users. All these new changes are in agreement with the new sign-in pages for Google accounts, which Google touts to make login experience consistent across all the devices. The primary impact will be on the organisations that use third-party apps inside their networks, along with those who use third-party SSO provider.

screen-shot-2017-09-19-at-12-26-48-amRelatedGoogle Launches New Payment Service ‘Tez’ That Uses Ultrasonic Audio to Transfer Money

Google new sign-in policies

Talking about the organisations that use third-party apps or provider, Google says in its blog post:

If you use third-party applications within your organization, or you use a third-party Single Sign-on (SSO) provider, we recommend contacting your developer(s) or SSO provider to see if any updates are necessary.

In a standalone announcement post on new sign-in page policies, Google reveals that the changes will affect “Google and 3rd-party applications on iOS, mobile browsers on iOS and Android, and web browsers (Chrome, Firefox, and other modern browsers).”

With these changes, users will be benefiting in a broader manner. Users of third-party SSO providers shall now be informed about the account authentication and permissions that they grant. Android apps that were using standard authentication methods have already started notifying users to select correct account information.

save-google-drive-photos-and-videosRelatedGoogle Automatically Trashes Your Android Backups After 60 Days of Inactivity

In a separate post on the G Suite blog, Google says:

It’s important that your users are presented with account information and credential consent, and apps should make this process easy and clear. One new change that you may now see is that only non-standard permission requests will be presented in the secondary consent screen in your application.

Currently, the permissions asked by an app are displayed jointly, but with new policies, users will now have a better view of permission they have granted to an app. Until now, the permission box used to show standard permissions such as “email address” and “profile”. Now, there will be an additional dialogue box that will show up whenever an app asks for more information other than the standard one.

Besides, users will be given more information about the third-party apps along with the clickable information like developer’s contact. It means that developers will now have to use a public e-mail address so that users will be able to contact them for support.

Throwing light on developer information requirements, Google says:

If your application may also be used by G Suite customers that employ a 3rd-party Single Sign-On (SSO) service, we recommend that you utilize the hd and/or login_hint parameters, if applicable. Even with the changes to the 3rd-party SSO auth flow, these parameters will be respected if provided. You can review the OpenID Connect page in the documentation for more information.

Users of G Suite might notice redirection when they try to sign into third-party SSO providers. If there is no signed-in account, then users will be asked to confirm the account when they sign-in for the first time. This drill will be done to ensure if they are signed into the correct G Suite account. For extra permissions, they will be redirected to confirmation pages.

Overall, it means that Google has enhanced its security rules and it will now be harder for third-party apps to get permissions. In the blog post, Google has specified that the rollout will take up to 15 days for feature visibility and will be available for all G Suite editions.

Submit