Hello @SaharD.34762 (Customer)​ Thank you for posting on our Community page!

Based on the two distinct symptoms you're seeing, we can actually pinpoint a few common culprits that the official documentation often glazes over. Let's break this down by what's happening on each side.

When you click the Google Workspace tile in Okta (IdP-initiated flow) and get this specific error, it means Okta successfully sent the user token to Google, but Google rejected it.

• The #1 Culprit: Username/Email Mismatch. Google is exceptionally strict about this. The Okta username being passed to Google must exactly match the Primary Email Address of that user in Google Workspace. If Okta is sending jdoe@domain.com but Google has john.doe@domain.com, Google will throw this exact error.
  • Fix: In Okta, go to the Google Workspace app -> Sign On tab -> Settings. Ensure the Application username format is set to Email (or whichever format perfectly matches your Google Workspace primary emails).
• Missing Account in Google: If you haven't set up user provisioning yet, check that the user you are testing with in Okta actually exists in Google Workspace.
• Testing with a Super Admin Account: By default, Google often prevents Super Admins from being locked out via SSO. If you are testing this integration using your primary Super Admin account, Google might be rejecting the IdP flow or forcing standard authentication. Always test with a standard, non-admin user account.

Why the Google Login Page hasn't changed

If you go straight to mail.google.com or drive.google.com (SP-initiated flow) and you just see the standard Google login screen instead of being redirected to Okta, the SSO policy isn't being enforced on Google's end.

• Third-Party SSO Isn't Enforced: In the Google Admin Console, go to Security > Authentication > SSO with third party IdP.
  • Ensure that Set up SSO with third party identity provider is actually checked.
  • Make sure you have assigned this SSO profile to the correct Organizational Unit (OU). If it's only enabled at the root level but disabled for the specific OU your test user is in, they will just see the normal Google login.
• Network Masks: In those same Google SSO settings, there is a field for a Network Mask. If you entered your office IP address here, Google will only route users to Okta if they are logging in from outside that IP (or inside, depending on how it's configured). Clear this field completely while you are testing to ensure SSO triggers everywhere.
• Certificate Mismatch: Ensure you downloaded the correct X.509 Certificate from Okta and uploaded it to the Google SSO settings. If the certificate doesn't match the Sign-In URL exactly, Google will quietly fail back to its own login screen.

As for the Opening a case with Support part, please note that Free trial/Integrator do not have access to Support at this time.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.