As an administrator, you can control how long different users can access the Google Cloud console and Cloud SDK without having to re-authenticate. For example, you might want users with elevated privileges, like project owners, billing administrators, or others with administrator roles, to re-authenticate more frequently than regular users. If you set a session length, they’re prompted to sign in again to start a new session.
The session length setting applies to:
- The Google Cloud console
- The gcloud command-line tool (Cloud SDK)
- Any applications (including third-party applications, or your own applications) that require user authorization for Google Cloud scopes. To review the apps requiring Google Cloud scopes in the Apps access control UI, see Control which third-party & internal apps access Google Workspace data.
Note: The Cloud session length setting does not apply to the console mobile app, and has limitations within the console. We recommend that you use this feature with Google session control, which applies a session length to all Google web properties.
Set the reauthentication policy
-
Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
-
In the Admin console, go to Menu
Security
Access and data control
- On the left, select the organizational unit where you want to set session length.
For all users, select the top-level organizational unit. Initially, an organizational unit inherits the settings of its parent. - Under Reauthentication policy, select Require reauthentication, and choose the Reauthentication frequency from the drop-down list.
The minimum frequency allowed is 1 hour, and the maximum is 24 hours. The frequency doesn't include how long a user has been inactive in the session. It is the fixed time that elapses before the user needs to sign in again.
You can also check the Exempt trusted apps box to exempt trusted apps from reauthentication. (Trusted apps are marked as Trusted on the App access control page. For more details, see Preparing for broad rollout below. See also, Control which third-party & internal apps access Google Workspace data.)
- Under Reauthentication method, select Password or Security key to specify how the user needs to reauthenticate.
- If you're setting the Reauthentication policy at the organizational unit level, click the Override button at the lower-right to keep the setting the same even if the parent setting changes.
- If the organizational unit's status is already Overridden, choose an option:
- Inherit—Reverts to the same setting as its parent.
- Save—Saves your new setting (even if the parent setting changes).
Changes can take up to 24 hours but typically happen more quickly. Learn more
Preparing for broad rollout
The reauthentication policy you configure here applies to all Google and third-party apps that access Google Cloud resources by requiring the Google Cloud scope. We recommend that you carefully test how the policy works for each of the apps with a small set of users—adding those users to the trusted apps list, before moving on to a broader rollout.
For instructions on reviewing the apps currently in use by your organization, see Control which third-party & internal apps access Google Workspace data. Make sure you filter for apps that require the Google Cloud service.
When the configured session length expires, the application will require the user to re-authenticate to continue operating—analogous to what would happen if an admin revoked the refresh tokens for that application.
Some applications may not gracefully handle the re-authentication scenario, causing confusing application crashes or stack traces. Some other applications are deployed for server-to-server use cases with user credentials instead of the recommended service account credential, in which case there is no user to periodically re-authenticate.
If you're impacted by these scenarios you can add these apps to a trusted list, temporarily exempting the apps from session length constraints, while implementing session controls for all other Google Cloud admin surfaces. Add the apps to the Trusted apps list in Apps access control, and enable the Exempt trusted apps checkbox in the Cloud session control setting.
Recover from reauth related error
You might get a reauth related error response from third-party apps after a session expires. To resume using these apps, users can sign in to the app again to start a new session.
Apps that use Application Default Credentials (ADC) with user credentials are considered third-party apps. These credentials are valid only for the configured session length. When that session expires, apps using ADC might also return a reauth related error response. Developers can reauthorize the app by running the gcloud auth application-default login command to obtain new credentials.
Considerations
When and how users sign in
If you need some users to sign in more frequently than others, place them in different organizational units. Then, apply different session lengths to them. That way, certain users won’t be interrupted to sign in again when it isn’t necessary.
If you require a security key, users who do not have one cannot use the console or Cloud SDK until they set it up. Once they have a security key, they can switch to using their password instead if they want.
Third-party identity providers
- With the console—If you require a user to re-authenticate using their password, they’re redirected to the identity provider (IdP). The IdP might not require the user to re-enter their password to start another console session, if the user already has a session active with the IdP—because they are using another application that caused the session to remain active.
If a user must re-authenticate by touching their security key, they can do this while using the console. They will not be redirected to the IdP.
- With the Cloud SDK—If a password is required for re-authentication, gcloud will require the user to execute the gcloud auth login command to renew the session. This will bring up a browser window, and the user will be taken to the IdP, where they may be prompted for credentials if there's no active session with the IdP.
If a user must reauthenticate by touching their security key, they can do this on the Cloud SDK. They will not be redirected to the IdP.