Posted by Naveen Agarwal, Identity team and Wesley Chun (@wescpy), Developer Advocate, G Suite

We’re constantly working to secure our users and their data. Earlier this year, we detailed some of our latest anti-phishing tools and rolled-out developer-focused updates to our app publishing processes, risk assessment systems, and user-facing consent pages. Most recently, we introduced OAuth apps whitelisting in G Suite to enable admins to choose exactly which third-party apps can access user data.

Over the past few months, we’ve required that some new web applications go through a verification process prior to launch based upon a dynamic risk assessment.

Today, we’re expanding upon that foundation, and introducing additional protections: bolder warnings to inform users about newly created web apps and Apps Scripts that are pending verification. Additionally, the changes we're making will improve the developer experience. In the coming months, we will begin expanding the verification process and the new warnings to existing apps as well.

Protecting against unverified apps 

Beginning today, we’re rolling out an “unverified app” screen for newly created web applications and Apps Scripts that require verification. This new screen replaces the “error” page that developers and users of unverified web apps receive today.

The “unverified app” screen precedes the permissions consent screen for the app and lets potential users know that the app has yet to be verified. This will help reduce the risk of user data being phished by bad actors.

The "unverified app" consent flow

This new notice will also help developers test their apps more easily. Since users can choose to acknowledge the ‘unverified app’ alert, developers can now test their applications without having to go through the OAuth client verification process first (see our earlier post for details).

Developers can follow the steps laid out in this help center article to begin the verification process to remove the interstitial and prepare your app for launch.

Extending security protections to Google Apps Script 

We’re also extending these same protections to Apps Script. Beginning this week, new Apps Scripts requesting OAuth access to data from consumers or from users in other domains may also see the "unverified app" screen. For more information about how these changes affect Apps Script developers and users, see the verification documentation page.

Apps Script is proactively protecting users from abusive apps in other ways as well. Users will see new cautionary language reminding them to “consider whether you trust” an application before granting OAuth access, as well as a banner identifying web pages and forms created by other users.

Updated Apps Script pre-OAuth alert with cautionary language

Apps Script user-generated content banner

Extending protections to existing apps 

In the coming months, we will continue to enhance user protections by extending the verification process beyond newly created apps, to existing apps as well. As a part of this expansion, developers of some current apps may be required to go through the verification flow.

To help ensure a smooth transition, we recommend developers verify that their contact information is up-to-date. In the Google Cloud Console, developers should ensure that the appropriate and monitored accounts are granted either the project owner or billing account admin IAM role. For help with granting IAM roles, see this help center article.

In the API manager, developers should ensure that their OAuth consent screen configuration is accurate and up-to-date. For help with configuring the consent screen, see this help center article. 

We’re committed to fostering a healthy ecosystem for both users and developers. These new notices will inform users automatically if they may be at risk, enabling them to make informed decisions to keep their information safe, and will make it easier to test and develop apps for developers.

Posted by Naveen Agarwal, Identity Team
(x-posted from Google Developers)

Last week, we took immediate action to protect users from a phishing attack that attempted to abuse the OAuth authorization infrastructure.

Today, we’re supplementing those efforts to help prevent these types of issues in the future. These changes may add some friction and require more time before you are able to publish your web application, so we recommend that you plan your work accordingly.

Updating app identity guidelines 

As our Google API user data policy states, apps must not mislead users. For example, app names should be unique to your application and should not copy others'.

To further enforce this policy, we are updating our app publishing process, our risk assessment systems, and our user-facing consent page in order to better detect spoofed or misleading application identities. You may see an error message as you’re registering new applications or modifying existing application attributes in the Google API Console, Firebase Console, or Apps Script editor as a result of this change.

New review processes and restrictions on web apps requesting user data 

We have also enhanced our risk assessment for new web applications that request user data.

Based on this risk assessment, some web applications will require a manual review. Until the review is complete, users will not be able to approve the data permissions, and we will display an error message instead of the permissions consent page. You can request a review during the testing phase in order to open the app to the public. We will try to process those reviews in 3-7 business days. In the future, we will enable review requests during the registration phase as well.

You can continue to use your app for testing purposes before it is approved by logging in with an account registered as an owner/editor of that project in the Google API Console. This will enable you to add additional testers, as well as initiate the review process.

We also recommend developers review our earlier post outlining their responsibilities when requesting access to user data from their applications. Our teams will continue our constant efforts to support a powerful, useful developer ecosystem that keeps users and their data safe.

Posted by Rodrigo Paiva, Product Manager, Nicholas Watson, Software Engineer and Wesley Chun, Developer Advocate

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 10, 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:

• Google and 3rd-party applications on iOS
• Mobile browsers on iOS and Android
• Web browsers (Chrome, Firefox and other modern browsers)

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.

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 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 10, 2017.

Posted by Michael Winser, Product Lead, Google Apps and Wesley Chun, Developer Advocate, Google Apps

Last week, we clarified the expectations and responsibilities when accessing Google user data via OAuth 2.0. Today, we’re announcing that in order to better protect users, we are increasing account security for enterprise Gmail users effective October 5, 2016. At this time, a new policy will take effect whereby users in a Google Apps domain, while changing their passwords on or after this date, will result in the revocation of the OAuth 2.0 tokens of apps that access their mailboxes using Gmail-based authorization scopes. Please note that users will not notice any specific changes on this date and their applications will continue to work. It is only when a user changes their password from that point moving forward that their Gmail-related tokens become invalid.

Developers should modify their applications to handle HTTP 400 or 401 error codes resulting from revoked tokens and prompt their users to go through the OAuth flow again to re-authorize those apps, such that they can access the user’s mailbox again (additional details below). Late last year, we announced a similar, planned change to our security policy that impacted a broader set of authorization scopes. We later decided not to move forward with that change for Apps customers and began working on a less impactful update as described above.

What is a revoked token?

A revoked OAuth 2.0 token no longer provides access to a user’s resources. Any attempt to use a revoked token in API calls will result in an error. Any existing token strings will no longer have any value and should be discarded. Applications accessing Google APIs should be modified to handle failed API calls.

Token revocation itself is not a new feature. Users have always been able to revoke access to applications in Security Checkup, and Google Apps admins have the ability to do the same in the Admin console. In addition, tokens that were not used for extended periods of time have always been subject to expiration or revocation. This change in our security policy will likely increase the rate of revoked tokens that applications see, since in some cases the process will now take place automatically.

What APIs and scopes are impacted?

To achieve the security benefits of this policy change with minimal admin confusion and end-user disruption, we’ve decided to limit its application to mail scopes only and to exclude Apps Script tokens. Apps installed via the Google Apps Marketplace are also not subject to the token revocation. Once this change is in effect, third-party mail apps like Apple Mail and Thunderbird―as well as other applications that use multiple scopes that include at least one mail scope―will stop accessing data upon password reset until a new OAuth 2.0 token has been granted. Your application will need to detect this scenario, notify the user that your application has lost access to their account data, and prompt them to go through the OAuth 2.0 flow again.

Mobile mail applications are also included in this policy change. For example, users who use the native mail application on iOS will have to re-authorize with their Google account credentials when their password has been changed. This new behavior for third-party mail apps on mobile aligns with the current behavior of the Gmail apps on iOS and Android, which also require re-authorization upon password reset.

How can I determine if my token was revoked?

Both short-lived access tokens and long-lived refresh tokens will be revoked when a user changes their password. Using a revoked access token to access an API or to generate a new access token will result in either HTTP 400 or 401 errors. If your application uses a library to access the API or handle the OAuth flow, then these errors will likely be thrown as exceptions. Consult the library’s documentation for information on how to catch these exceptions. NOTE: because HTTP 400 errors may be caused by a variety of reasons, expect the payload from a 400 due to a revoked token to be similar to the following:

{
  "error_description": "Token has been revoked.", 
  "error": "invalid_grant"
}

How should my application handle revoked tokens?

This change emphasizes that token revocation should be considered a normal condition, not an error scenario. Your application should expect and detect the condition, and your UI should be optimized for restoring tokens.

To ensure that your application works correctly, we recommend doing the following:

• Add error handling code around API calls and token refreshes that can detect revoked tokens.
• Upon detecting a revoked token, disable any application features that rely on Google API access until the user can re-authorize your application. For example, suspend any recurring background jobs that sync data with a Google API which may be affected.
• Notify the user that access has been revoked and prompt them to re-authorize access to their resources.
  • If your app interacts directly with the user, you will need to prompt the user to re-authorize, i.e., send an email to the user and/or show them an alert the next time they open your application.
  • However, if your app runs independently of the user, say a background app that uses the Gmail API, you'll need to notify the user through email or some other mechanism.
  • Provide a streamlined UI for re-authorizing access. Avoid having users navigate through your application to find the original setting.
  • Note that revoked tokens will result in similar error messages regardless of how the token was revoked. Your messaging should not assume that the token was revoked due to a password change.

If your application uses incremental authorization to accrue multiple scopes in the same token, you should track which features and scopes a given user has enabled. The end result is that if your app requested and obtained authorization for multiple scopes, and at least one of them is a mail scope, that token will be revoked, meaning you will need to prompt your user to re-authorize for all scopes originally granted.

Many applications use tokens to perform background or server-to-server API calls. Users expect this background activity to continue reliably. Since this policy change also affects those apps, this makes prompt notification requesting re-authorization even more important.

What is the timeline for this change?

To summarize, properly configured applications should be expected to handle invalid tokens in general, whether they be from expiration, non-existence, and revocation as normal conditions. We encourage developers to make any necessary changes to give their users the best experience possible. The policy change is planned to take effect on October 5, 2016.

Please see this Help Center article and FAQ for more details and the full list of mail scopes. Moving forward, any additional scopes to be added to the policy will be communicated in advance. We will provide those details as they become available.

Posted by: Chuck Coulson, Head of Google Apps and Drive Technology Partnerships

Last month we announced Google Drive for Work, which includes advanced Drive auditing to give organizations control, security and visibility into how files are shared. This new security feature helps companies and IT managers protect confidential information and gain insights into how their employees work.

Drive audit helps IT admins view activity on documents, such as uploading and downloading files, renaming files, editing and commenting, and sharing with others. Filters make it easy to sort and find details like IP address, date range, document title and owner’s email address. To make advanced auditing reports easier to manage, admins can set up alerts for important events like files being shared outside the organization.

To help organizations derive even more value from Drive for Work, we’ve been working with partners to give you even more capabilities through the Drive Audit API:

• Backupify protects your Google Apps data through secure, automatic, daily backup allowing IT users to easily search and restore files with advanced administrative features, safeguarding your business from data loss caused by user errors, malicious deletions, hackers, and app errors. (website, blogpost)
• BetterCloud, through their flagship cloud management and security tool, FlashPanel, has enhanced their offering through the Audit API to provide additional controls and insight. (website, blogpost)
• CloudLock, who provides a pure-cloud Data Loss Prevention (DLP) solution for SaaS applications, has released a new version of CloudLock for Google Drive, leveraging the new Google Drive audit APIs, to enable large organizations to extend their enterprise security controls to the cloud. (website, blogpost)
• SkyHigh for Google Drive delivers Data Loss Prevention (DLP), mobile-to-cloud support, application auditing, data discovery, and anomaly detection without changing the Google Drive experience users love. (website, blogpost)

And this is only the beginning. We invite developers and customers alike to get started with the Audit API to provide additional advanced security solutions for Google Drive. Learn more by visiting developers.google.com.

Google is committed to enabling organizations to be successful by leveraging a large community of ISVs. One of the areas we constantly invest in is our APIs, that allow customers and ISVs to extend the functionality of the Google Apps platform. If you’d like to join our ISV community, check out the developers.google.com site. For a list of ISVs supporting Google Apps, please visit the Google Apps Marketplace.