Updates to end user consent for 3rd-party apps and Single Sign-on providers

APR 03, 2017
Originally Posted on G Suite Developers Blog
Posted by Rodrigo Paiva, Product Manager & Nicholas Watson, Software Engineer, Identity, and Wesley Chun, Developer Advocate, G Suite


At Google, we're mindful of keeping our users' data and account information secure. So whether you're writing an app that requires access to user data or helping your users change their passwords, we'll keep you up-to-date on policy changes, and now today, when it comes to consent and 3rd-party applications. Starting April 5, 2017, if you're an application developer or a 3rd-party Single Sign-On (SSO) provider, your G Suite users may encounter a redirect when they authenticate with your identity service to make it clear to users which account they're authenticating as well as the permissions they're granting to applications.

These changes will occur on these platforms:
Note that Android applications that use the standard authentication libraries are already prompting users to select appropriate account information, so they're not impacted by these changes.

More visibility with new permission requests for your application 

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 when an application requests permissions, all of them are displayed together. However, users should have greater visibility into permissions being requested beyond the standard "email address" and "profile" consent. By clicking to select their account, a user consents to these core permissions,. The secondary consent screen will appear only if additional permissions are requested by the application.

Only non-standard permissions will be presented in the secondary consent screen that the user must approve.

Along with these changes, your application name will be more visible to users, and they can click-through to get your contact information. We recommend application developers use a public-facing email address so that users can quickly contact you for support or assistance. For more details, check out this developer guide.

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.


An application that uses the hd parameter to specify the domain name automatically

Changes coming for 3rd-party SSO redirection

G Suite users may also notice redirection when signing into 3rd-party SSO providers. If no accounts are signed in, the user must confirm the account after signing in to the 3rd-party SSO provider to ensure that they're signed in with the correct G Suite account:
The end user who has just signed in with one Google account should select that account as confirmation.

As mentioned, by clicking to the select their account, a user is opting into "email address" and "profile" consent. Once the user consents to any additional non-standard permissions that may be requested, they will be redirected back to your application.

If the user is already signed in to one or more accounts that match the hd hint, the Account Chooser will display all of the accounts and require the user to select the appropriate G Suite account before being redirected to the 3rd-party SSO provider then back to your application:

A user who is signed into several Google accounts will be required to choose the appropriate account.

See updates starting April 2017

These changes will help your users understand their permissions more clearly across all platforms, whether they're using Google or a 3rd-party SSO provider for authentication. We've started to roll out the new interstitial page on iOS devices, and changes for browsers will begin to roll out starting April 5, 2017.

posted in:
Previous
Next