Configuring access · Topic 4 of 7
Password, Session, SAML, OAuth and 2-Step Verification
Set password and session policies for Google Cloud users, configure SAML SSO and OAuth app access, and enforce 2-Step Verification with security keys.
- 5 min
- Password policy in the Admin console applies only when Google holds the password.
- Google Cloud session control sets reauthentication frequency for the console and gcloud.
- Cloud Identity is the SAML service provider for SSO, and can be an IdP for SAML apps.
What it is
Authentication proves a user is who they claim to be before IAM decides what they may do. For Google Cloud users this is set in the Google Admin console of Cloud Identity or Google Workspace, or delegated to a third-party IdP through SAML.
The engineer sets three things: how strong passwords and sessions are, how users and apps sign in (SAML for users, OAuth for apps), and which second factor is required (2-Step Verification, 2SV).
How it works
Password policy
When Google holds the password, set the policy under password management in the Admin console, per organizational unit.
| Setting | Secure choice |
|---|---|
| Strength | Enforce strong passwords |
| Length | A minimum well above the lowest allowed value |
| Enforce at next sign-in | On, so existing weak passwords must change |
| Reuse | Do not allow reuse |
| Expiration | Optional; modern guidance favours strong passwords plus 2SV over frequent forced changes |
With SAML SSO the password belongs to the IdP, so its policy is set there. Google's password policy then applies only to accounts that still sign in with Google, such as super admins.
Session management
Google Cloud session control in the Admin console sets how often users of the Google Cloud console and the gcloud CLI must reauthenticate, and whether with a password or a security key. Use shorter sessions for privileged groups.
Separate web session length settings apply to other Google services. With SSO, the IdP session and its own timeout also matter, so align both.
SAML for single sign-on
Cloud Identity can act in both SAML roles.
| Role | Setup | Use |
|---|---|---|
| Service provider | SSO profile with the IdP sign-in URL and certificate, assigned to organizational units or groups | Users sign in to Google with Okta, Entra ID or AD FS |
| Identity provider | A custom SAML app in the Admin console | Users sign in to a third-party app with their Google identity |
For SSO into Google, the IdP must send the user's primary email as the NameID so it matches the Cloud Identity account. Assigning profiles per group lets you pilot SSO with a small group first.
OAuth for applications
OAuth 2.0 lets an application call Google APIs on behalf of a user, after the user consents to specific scopes. A security engineer controls both sides.
| Control | Where | Effect |
|---|---|---|
| OAuth consent screen user type | Google Cloud project | Internal restricts the app to users in your organization |
| OAuth client and redirect URIs | Google Cloud project | Only registered redirect URIs receive codes |
| App access control | Admin console API controls | Mark third-party apps as trusted, limited or blocked |
| Google Cloud scope restriction | Admin console | Stop unreviewed third-party apps from getting Cloud Platform access |
| Domain-wide delegation | Admin console | Lets a service account act as any user; grant only exact scopes, review often |
OAuth is also the sign-in flow behind Identity-Aware Proxy, covered in the perimeter chapter.
Enforcing 2-Step Verification
2SV is configured per organizational unit or group.
| Setting | Recommendation |
|---|---|
| Allow users to turn on 2SV | On |
| Enforcement | On, with an enforcement date announced to users |
| New user enrollment period | Short, so new accounts cannot stay unprotected for long |
| Methods | Only security key for admins and privileged users; any method except text and voice codes for others |
| Backup codes | Allowed, so users can recover without help desk resets |
Security keys resist phishing because they check the site's origin. For the most targeted users, Google's Advanced Protection Program adds stricter protections.
When users sign in through a SAML IdP, the IdP's MFA protects that sign-in. Make sure the IdP enforces MFA, and keep Google 2SV for accounts that sign in directly, especially super admins.
A worked example
A company federates with Okta but finds three super admins and a break-glass account signing in with Google passwords and SMS codes. Cloud engineers also stay signed in to the console for weeks.
The engineer moves admins to a group that enforces security keys only, with a short enrollment period. Google Cloud session control requires reauthentication with a security key every few hours for the admin group, and the Okta MFA policy is confirmed for everyone else.
How the exam asks about this
- "Administrators must use a phishing-resistant second factor." Enforce 2SV with the security key only method for the admin organizational unit or group.
- "Cloud console users must reauthenticate every 8 hours." Configure Google Cloud session control in the Admin console.
- "Stop third-party apps that users authorize from accessing Google Cloud data unless the security team approves them." Use API controls (app access control) to restrict unreviewed apps and trust only approved ones.
What to remember for the exam
- Password policy in the Admin console applies only when Google holds the password.
- Google Cloud session control sets reauthentication frequency for the console and gcloud.
- Cloud Identity is the SAML service provider for SSO, and can be an IdP for SAML apps.
- OAuth app access is governed by consent screen type, scopes and Admin console API controls.
- Enforce 2SV with security keys for privileged users; IdP MFA covers SSO sign-ins.
Domain-wide delegation lets a service account impersonate any user in the domain for the scopes granted. A leaked key for such an account is a domain-wide breach.
Common mistakes
Setting a Google password policy and expecting it to cover SSO users. Federated users never use a Google password. Change the policy in the IdP.
Turning on 2SV without enforcing it. Allowing 2SV only lets users opt in. Enforcement with a date is what makes it mandatory.
Leaving SMS as an admin's only second factor. Text codes can be phished or intercepted. Require security keys for privileged accounts.
Check yourself
Where do you require Google Cloud console users to reauthenticate every few hours?
In Google Cloud session control in the Admin console, setting the reauthentication frequency and method.
Which 2SV method should be enforced for super admins?
Security keys only, because they are phishing resistant.
What does setting an OAuth consent screen to Internal do?
It limits the app to users in your own organization, so external accounts cannot authorize it.
Topic 4 of 7 in Configuring access
Test yourself on Configuring access
The full Google Cloud Professional Cloud Security Engineer question bank has 749 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.