Tag Archives: identity

Stronger protection for sensitive Google Workspace account actions

What’s changing 

We’re introducing stronger safeguards for sensitive actions taken in your Google Workspace account. These apply to actions that, when done by hijackers, can have far reaching consequences for the account owner or the organization it belongs to. 


Google will evaluate the session attempting the action, and if it’s deemed risky, it will be challenged with a “Verify it’s You” prompt. Through a second and trusted factor, such as a 2-step verification code, users can confirm the validity of the action. For example, if a malicious actor gains access to your account and attempts to change the name on your account, the action will be blocked until the true account owner can verify that this was intentional. 


Note that this feature only supports users that use Google as their identity provider and actions taken within Google products. SAML users are not supported at this time. See below for more information. 



Who’s impacted 

Admins and end users 


Why it matters 

This added layer of security helps to intercept bad actors who have gained access to a user's account, further protecting their data and your organization's sensitive information. Additionally, these challenge attempts will be logged as an audit event allowing for further admin investigation. 

Additional details 

In the Admin console under Users > “UserName” > Security, admins can toggle login challenges OFF for ten minutes if a user gets stuck behind a "verify it's you prompt". We strongly recommend only using this option if contact with the user is credibly established, such as via a video call. 

Getting started 


Rollout pace 


Availability 

  • Available to all Google Workspace customers, as well as legacy G Suite Basic and Business customers 

Resources 

Migrate unmanaged accounts to your domain using new “UserInvitation” API functionality

What’s changing 

We’re introducing new API functionality which allows you to automate the process of finding conflicting accounts and inviting them to join your organization. 


Who’s impacted 

Admins, end users, and developers 


Why you’d use it 

When employees create a Google account using one of your organization’s domains to access Google services, this is known as an unmanaged account. Unmanaged accounts are not ideal for managing users and keeping their work data secure. 


Additionally, should an admin try to create a managed account with the same name, this conflict will prevent a managed account from being created. Using the UserInvitation API functionality, you can send a request to convert their personal account to a Google Workspace account. 


While the same action can be manually performed with the Transfer Tool, the API allows conflicting accounts to be identified and remediated programmatically, using logic that best suits your needs.


Getting started 

  • Admins and Developers: 
  • End users: 
    • If you accept the request from your admin to transfer their account, your admin will be granted access to their data and the ability to manage your account. 
    • If you don’t accept the invitation, you will have to rename your account. Your administrator can create a new, managed account for you. 

Rollout pace 


Availability 

  • Available to Google Workspace Business Starter, Business Standard, Business Plus, Enterprise Standard, Enterprise, Cloud Identity Premium and Cloud Identity Free customers 
  • Not available to Google Workspace Essentials,, Enterprise Essentials, Education Standard, Enterprise Plus, Education Fundamentals, Education Plus, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers 

Resources 

Google Workspace Updates Weekly Recap – June 10, 2022

New updates 

Unless otherwise indicated, the features below are fully launched or in the process of rolling out (rollouts should take no more than 15 business days to complete), launching to both Rapid and Scheduled Release at the same time (if not, each stage of rollout should take no more than 15 business days to complete), and available to all legacy Google Workspace and G Suite customers. 

Find and insert GIFs faster on Google Chat on iOS Devices 
You can now easily browse, select and insert GIFs while using the Chat iOS mobile app. When enabled by your admin, select the “GIF” icon in the Google Chat compose bar. We hope this makes it easier for you to express yourself when interacting with your colleagues. | Learn more. 


Set a custom duration for "Do Not Disturb" in Google Chat on web and iOS devices 
You can now set the duration of your "Do Not Disturb" status to a specific date and time. We hope this feature gives you the flexibility to mute notifications the way it best suits you. This feature is now available on web, Android and iOS devices. | Learn more. 


Previous announcements 

The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.


New admin controls for access to discoverable spaces in Google Chat 
We’ve added the ability for Admins to set the default for newly created spaces and enable sharing scoped to specific audiences. | Learn more. 

Available to Google Workspace Business Plus, Enterprise Standard, Enterprise Plus, Education Plus, and Education Standard customers. 


Context-Aware Access remediator provides more context for access denials 
Admins using Context-Aware Access can now provide more information to end users when their access is blocked using the user remediation feature. | Learn more.

Available to Google Workspace Enterprise Plus, Education Plus, and Cloud Identity Premium customers. 


Mark your important tasks with a star in Google Tasks 
You can now mark important tasks with a star in Google Tasks. Additionally, you’ll be able to view or sort your starred items across various tasks lists in the new starred view. | Learn more. 
 
For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).

Context-Aware Access remediator provides more context for access denials

What’s changing 

Admins using Context-Aware Access can now provide more information to end users when their access is blocked using the user remediation feature. This feature will help end users quickly understand what steps they need to take to re-access Google Workspace. 


Who’s impacted 

Admins and end users 


Why it’s important 

Context-Aware Access allows admins to assign granular access control policies to apps based on attributes such as user identity, location, device security status, IP address, etc. When a user or device does not meet the requirements, they will be unable to access the respective apps. 


Currently, the only course of action for end users is to contact their admin for further support, which causes unnecessary delay, churn, and support calls. End user remediation will enable admins to provide their users with details about why their access has been denied and what steps need to be taken to restore access. 


Further, once an admin enables remediation, they’ll see a message in the Admin console noting whether remediation is enabled. Each remediation action corresponds to an attribute which is causing access to be denied. Visit the Help Center for a list of the possible remediation actions that may be shown to end users. 


Getting Started 

  • Admins: Admins can apply the new remediation messaging within the Context-aware Access section of the admin UI by navigating to Security > Context-Aware Access > User Message. Visit the Help Center to learn more about allowing users to unblock apps with remediation messages in Context Aware Access. 



  • End Users: End users will see the following message if they try to access a Google Workspace app when access is not allowed. 




Rollout pace 


Availability 

  • Available to Google Workspace Enterprise Plus, Education Plus, and Cloud Identity Premium customers 
  • Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Education Fundamentals, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers 

Resources 

Send group membership information in outbound SAML responses

Quick launch summary 

We’re adding the ability for admins to configure and send group membership information as part of SAML responses. 


Currently, you are able to configure SSO to send user attributes in the SAML response when a user logs in to an app using SAML SSO. With this launch, admins can configure SSO to send group membership information to the application. Apps can then use these attributes to assess user authorization and to implement other business logic. 

Getting started 






Rollout pace 


Availability 

  • Available to all Google Workspace customers, as well as legacy G Suite Basic and Business customers and Cloud Identity customers 

Resources 

Google Workspace Updates Weekly Recap – May 13, 2022

New updates 

Unless otherwise indicated, the features below are fully launched or in the process of rolling out (rollouts should take no more than 15 business days to complete), launching to both Rapid and Scheduled Release at the same time (if not, each stage of rollout should take no more than 15 business days to complete), and available to all legacy Google Workspace and G Suite customers. 


New idle status in Google Chat 
In Google Chat on web and Chat in Gmail, you'll see an orange clock badge for users that were recently active in Chat, but aren't currently active. We hope this makes it easier to determine the best time to connect with your colleagues. Visit the Help Center to learn more about availability statuses in Google Chat. 





Changes to the default Host Management controls in Google Meet for users with personal accounts 
The default setting for Host Management controls is changing for users with personal Google accounts. Previously, Host Management controls were ON by default — going forward, this setting will be OFF by default for new meetings. There are no changes to the behavior for Google Workspace customers or Google Workspace Individual users.



Previous announcements


The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.


Improved user interface for sharing your working location in Google Calendar
This update improves the working location feature by offering the same functionality for easily entering and updating location information in a more compact format that uses screen space more efficiently. | Learn more here and here. 

Available to Google Workspace Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Plus, and Nonprofits, as well as G Suite Business customers. 


Easily search for Google Meet content in Google Drive
In Google Drive, you can now use app:”Google Meet” to easily find and organize Meet content such as Meet recordings, meeting transcripts, and more. | Learn more.


Import existing custom themes to new Google Sites
You can now import a custom theme from one new Google Site to another. | Learn more.


Create Spaces and Add Members with the Google Chat API, available in Developer Preview
Using the Google Chat API, you can now programmatically create new Spaces and add members to those Spaces. This functionality is available in preview – developers can apply for access through our Google Workspace Developer Preview Program. | Learn more.


Require email verification to book appointments in Google Calendar
When using appointment scheduling in Google Calendar, you can now opt to have users verify their email before booking an appointment. When enabled, the user must be signed into a Google account or validate their email address using a PIN code to complete the booking. | Learn more.

Available to Google Workspace Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Standard, Education Plus, the Teaching and Learning Upgrade, and Nonprofits customers.


New delegated VirusTotal privilege in the Alert Center
In 2021, we announced an integration between the Alert Center and VirusTotal. At that time, any admin who had the Alert Center privilege could access all VirusTotal reports. Now, we’ve added the ability for admins to control who can view VirusTotal reports. | Learn more.

Available for Google Workspace Business Plus, Enterprise Standard, Enterprise Plus, Education Standard and Education Plus.


Set up SSO profiles for multiple third-party identity providers with the Multi-IdP SSO beta launch
You can further customize authentication by setting up single sign-on (SSO) profiles for multiple identity providers and then configuring authentication for each group or OU. This feature is available beginning today as an open beta, which means you can use it without enrolling in a specific beta program. | Learn more.


For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).

Set up SSO profiles for multiple third-party identity providers with the Multi-IdP SSO beta launch

What’s changing 

For over a decade, we have given admins the ability to configure authentication through a third-party identity provider . In 2021, we expanded this capability by making it possible to choose between third-party identity provider or Google authentication for specific groups or organizational units (OUs). 


Now, you can further customize authentication by setting up single sign-on (SSO) profiles for multiple identity providers and then configuring authentication for each group or OU. This feature is available beginning today as an open beta, which means you can use it without enrolling in a specific beta program.


You can now set up SSO profiles for multiple third-party identity providers




Who’s impacted


Admins

Why you’d use it

Currently, you can configure SSO with a third-party identity provider to apply to your entire domain and then require a subset of your users, such as vendors or contractors, to authenticate with Google instead. However, if you have more than one identity provider, you might require greater customization of authentication options. For example, your company might be migrating from one provider to another, or it might have acquired another company that uses a different provider.


The Multi-IdP SSO beta lets you set up SSO profiles for each of your third-party identity providers, giving you the flexibility to specify the authentication method for various users in your organization as needed.

Getting started

  • Admins: In the Admin console, navigate to Security > Settings > Set up single sign-on (SSO) with a third party IdP > Manage SSO Profile assignments. Visit the Help Center to learn more about setting up SSO for your organization.


Go to the Security settings to set up SSO profiles for third-party identity providers

  • End users: There is no end user setting for this feature.

Rollout pace

  • This feature is available now for all users.


Availability

  • Available to Google Workspace Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Plus, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers
  • Available to all Cloud Identity customers
  • ​​Not available to Google Workspace Essentials customers
  • Not available to users with personal Google Accounts

Resources

Making Google OAuth interactions safer by using more secure OAuth flows

Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager, Google

At Google, we constantly strive to provide safer ways for users to sign-in and share their Google account data with third-party applications. In the spirit of that work, we will be rolling out a set of protections against phishing and app impersonation attacks during the OAuth interactions.

The Google sign-in and authorization flows are powered by the Google OAuth platform and over the years we have developed and supported a number of ways for app developers to integrate with supported OAuth flows. With the goal of keeping users safer online, we will end support for two legacy flows and will require developers to migrate to alternative implementation methods that offer greater protections.

To ensure a smooth transition and avoid any service interruption we will give ample time to implement and meet the compliance dates which are specified below. We will share further updates on this rollout via email so please make sure your support email address is up to date in project settings on the Google API console.

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types

The Loopback IP address flow is vulnerable to man in the middle attack where a malicious app, accessing the same loopback interface on some operating systems, may intercept the OAuth response and gain access to the authorization code. We intend to remove this threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The existing clients will be able to migrate to more secure implementation methods. New clients will be unable to use this flow starting on March 14, 2022.

What do I need to do

Determine if your app is using the Loopback IP address flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or

http://localhost:port

Migrate to an alternative flow

If your app is using the Loopback IP address method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
  • Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests one month before the compliance date
  • Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients

OAuth out-of-band (oob) flow will be deprecated

OAuth out-of-band (OOB) is a legacy flow developed to support native clients which do not have a redirect URI like web apps to accept the credentials after a user approves an OAuth consent request. The OOB flow poses a remote phishing risk and clients must migrate to an alternative method to protect against this vulnerability. New clients will be unable to use this flow starting on Feb 28, 2022.

What do I need to do

Determine if your app is using the OOB flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=urn:ietf:wg:oauth:2.0:oob or urn:ietf:wg:oauth:2.0:oob:auto or oob

Migrate to an alternative flow

If your app is using the OOB method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
  • Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests
  • Oct 3, 2022 - the OOB flow is deprecated for existing clients

User-facing warning message

A user-facing warning message may be displayed for non-compliant requests one month before the aforementioned OAuth methods are due to be blocked. The message will convey to the users that the app may be blocked soon while displaying the support email that you have registered in the OAuth consent screen in Google API Console.

[Sample user-facing warning]

The developers can acknowledge the user-facing warning message and suppress it by passing a query parameter in the authorization call as shown below.

  • Go to the code in your app where you send requests to Google's OAuth 2.0 Authorization Endpoint.
  • Add a parameter with a value of the enforcement date
    • For OOB: Add an ack_oob_shutdown parameter with a value of the enforcement date: 2022-10-03. Example: ack_oob_shutdown=2022-10-03
    • For Loopback IP address: Add an ack_loopback_shutdown parameter with a value of the enforcement date: 2022-08-31. Example: ack_loopback_shutdown=2022-08-31

User-facing error message

If an app is not updated to meet compliance by the required date the authorization requests will be blocked and users may encounter an invalid request error screen (sample shown below).

[Sample user-facing error]

Making Google OAuth interactions safer by using more secure OAuth flows

Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager, Google

At Google, we constantly strive to provide safer ways for users to sign-in and share their Google account data with third-party applications. In the spirit of that work, we will be rolling out a set of protections against phishing and app impersonation attacks during the OAuth interactions.

The Google sign-in and authorization flows are powered by the Google OAuth platform and over the years we have developed and supported a number of ways for app developers to integrate with supported OAuth flows. With the goal of keeping users safer online, we will end support for two legacy flows and will require developers to migrate to alternative implementation methods that offer greater protections.

To ensure a smooth transition and avoid any service interruption we will give ample time to implement and meet the compliance dates which are specified below. We will share further updates on this rollout via email so please make sure your support email address is up to date in project settings on the Google API console.

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types

The Loopback IP address flow is vulnerable to man in the middle attack where a malicious app, accessing the same loopback interface on some operating systems, may intercept the OAuth response and gain access to the authorization code. We intend to remove this threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The existing clients will be able to migrate to more secure implementation methods. New clients will be unable to use this flow starting on March 14, 2022.

What do I need to do

Determine if your app is using the Loopback IP address flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or

http://localhost:port

Migrate to an alternative flow

If your app is using the Loopback IP address method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
  • Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests one month before the compliance date
  • Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients

OAuth out-of-band (oob) flow will be deprecated

OAuth out-of-band (OOB) is a legacy flow developed to support native clients which do not have a redirect URI like web apps to accept the credentials after a user approves an OAuth consent request. The OOB flow poses a remote phishing risk and clients must migrate to an alternative method to protect against this vulnerability. New clients will be unable to use this flow starting on Feb 28, 2022.

What do I need to do

Determine if your app is using the OOB flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=urn:ietf:wg:oauth:2.0:oob or urn:ietf:wg:oauth:2.0:oob:auto or oob

Migrate to an alternative flow

If your app is using the OOB method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
  • Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests
  • Oct 3, 2022 - the OOB flow is deprecated for existing clients

User-facing warning message

A user-facing warning message may be displayed for non-compliant requests one month before the aforementioned OAuth methods are due to be blocked. The message will convey to the users that the app may be blocked soon while displaying the support email that you have registered in the OAuth consent screen in Google API Console.

[Sample user-facing warning]

The developers can acknowledge the user-facing warning message and suppress it by passing a query parameter in the authorization call as shown below.

  • Go to the code in your app where you send requests to Google's OAuth 2.0 Authorization Endpoint.
  • Add a parameter with a value of the enforcement date
    • For OOB: Add an ack_oob_shutdown parameter with a value of the enforcement date: 2022-10-03. Example: ack_oob_shutdown=2022-10-03
    • For Loopback IP address: Add an ack_loopback_shutdown parameter with a value of the enforcement date: 2022-08-31. Example: ack_loopback_shutdown=2022-08-31

User-facing error message

If an app is not updated to meet compliance by the required date the authorization requests will be blocked and users may encounter an invalid request error screen (sample shown below).

[Sample user-facing error]