How to Implement SSO for SOC 2: Okta and Google Workspace

Why SSO Matters for SOC 2

Single Sign-On (SSO) is one of the highest-impact controls you can implement for SOC 2. It centralises user authentication, enabling: centralised MFA enforcement (one policy covers all applications), rapid access revocation (disable one account to remove access to all SSO-connected apps), comprehensive access reviews (one report shows all application access), and detailed authentication audit logs.

Without SSO, you must manage user accounts, MFA, and access reviews separately for each application. With 10–20 SaaS tools in a typical startup stack, this quickly becomes unmanageable.

Choosing an Identity Provider

Okta: the market leader for enterprise B2B. 7,000+ pre-built SAML/OIDC integrations, advanced MFA policies, lifecycle management (automated provisioning/deprovisioning), and detailed audit logs. Most SOC 2 auditors are familiar with Okta and accept its exports as high-quality evidence.

Google Workspace: strong choice if your team already uses Gmail and Google apps. Google Workspace acts as an IdP via SAML for hundreds of applications. Native MFA (2-Step Verification) with security key support. Included in Google Workspace subscription at no additional IdP cost.

Microsoft Azure AD (Entra ID): best if your team uses Microsoft 365 heavily. Strong integration with the Microsoft ecosystem. Conditional Access policies provide granular MFA and access control.

Okta Setup for SOC 2

Initial setup: enable Okta as the IdP for your highest-priority applications first — AWS (via AWS IAM Identity Center), GitHub (SAML SSO), Slack, and any custom applications.

MFA configuration: in Okta, create a Sign-On Policy that requires MFA for all users, with no bypass options except device trust. Use Okta Verify or FIDO2 security keys — these are phishing-resistant and preferred by auditors over SMS OTP.

Lifecycle management: enable Okta provisioning for key applications (via SCIM if supported). Adding a user to an Okta group automatically provisions their access, and deactivating them in Okta automatically revokes access everywhere.

Google Workspace SSO

Google Workspace can serve as an IdP for SAML-enabled applications. In the Google Admin Console: Apps > Web and Mobile Apps > Add App > Add custom SAML app. Configure SAML metadata for each application.

For GitHub: use GitHub's built-in SAML SSO with Google Workspace as the IdP. For Slack: configure Slack SAML with Google Workspace. For AWS: use AWS IAM Identity Center with Google Workspace as the SAML IdP.

Google Workspace 2-Step Verification: enforce 2SV for all users in the Admin Console under Security. Use hardware security keys or Google Authenticator. Disable SMS-based 2SV for higher security environments.

MFA Enforcement

MFA is one of the first things SOC 2 auditors check. Configuration alone is not enough — you must enforce it (no bypass, no "MFA recommended" settings) and generate evidence that it is active for all users.

Evidence for auditors: export a user report from your IdP showing MFA status for every user. In Okta: Reports > Reports > User Status. The report should show 100% of users with MFA enrolled and required.

Define an exception process: if there are service accounts or API-only accounts without MFA, document each one with justification and compensating controls.

Application Coverage and Exceptions

SOC 2 auditors will ask: what percentage of your applications require SSO authentication? The target is 100% of applications with access to production systems or sensitive data.

Build an application inventory: list every SaaS tool used, its risk tier, whether it is SSO-connected, and if not, why (technical limitation, no SAML support) and the compensating control (e.g. strong password + MFA enforced natively in the application).

Exceptions require documentation. A note that says "Application X does not support SAML SSO — users access via individual accounts with MFA enforced natively" is an acceptable exception.

Evidence for Auditors

Evidence to collect and store for SOC 2: IdP user report (MFA status for all users, ideally monthly exports during observation period), SSO application list (which apps are connected), sign-on policy configuration screenshot (MFA required, policy details), and access logs for a sample period.

For Okta: the System Log records all authentication events, MFA usage, and admin changes. This is valuable evidence for CC7.2 (monitoring) and CC6.1 (access control).