IAM Identity Center + Google Workspace: IdP-initiated SAML (launcher tile / Test SAML Login) fails with "couldn't verify your sign-in credentials" — SP-initiated works fine

The issue you are experiencing is a known limitation between Google Workspace and AWS IAM Identity Center regarding IdP-initiated SAML flows, specifically related to the RelayState parameter.

The Root Cause: While SP-initiated flows (starting at the AWS access portal) work perfectly because AWS generates the request and handles the state, IdP-initiated flows (clicking the launcher tile in Google Workspace) send an "unsolicited" SAML response.

For AWS IAM Identity Center to accept an unsolicited SAML response, the IdP must support sending a specific RelayState endpoint URL (essentially deep-linking the user to the AWS portal). Google Workspace currently does not support dynamic RelayState for IdP-initiated SSO.

Because Google Workspace sends the SAML assertion without the expected RelayState routing information, AWS Identity Center fails to validate the context of the unsolicited login. This results in the generic "We couldn't verify your sign-in credentials" error, and because the failure happens at the edge validation layer before a session context is established, it often drops before generating a CloudTrail event.

Workarounds:

1. Hide the Tile: Since the SP-initiated flow works, the most common solution is to hide the AWS SAML tile from the Google Workspace app launcher to prevent users from clicking it and encountering the error. Instruct users to bookmark your AWS access portal URL (https://<my-company>[.awsapps.com/start](https://.awsapps.com/start)) directly.
2. Custom App (Not Recommended): Some administrators attempt to create a custom bookmark app in Google Workspace that simply redirects to the AWS SP-initiated portal URL, replacing the broken SAML app tile.

The troubleshooting steps regarding dual-stack endpoints apply primarily to CLI device-code flows and will not resolve this specific SAML RelayState limitation between Google and AWS.

see also:

• https://repost.aws/questions/QUQhTKrAQjSSOcQ73BJlXYmg/facing-issues-while-setting-up-google-workspace-formerly-g-suite-as-identity-provider-for-aws-workspaces-using-saml-2-0
• https://docs.aws.amazon.com/singlesignon/latest/userguide/troubleshooting.html

A known issue has been reported where aws sso login --use-device-code fails in dual-stack environments, triggering the generic error message: "Something doesn't compute / We couldn't verify your sign-in credentials." This issue arises from a mismatch between the endpoint family configured for the IdP and the one expected by AWS; setting AWS_USE_DUALSTACK_ENDPOINT=true serves as a workaround.

Furthermore, official documentation states that Google Workspace does not support multiple SAML ACS URLs for IAM Identity Center applications. While this limitation is noted to impact multi-region support, it suggests that even in single-region configurations, Identity Center performs internal checks to ensure endpoint family consistency.

Why SP-initiated flows succeed while IdP-initiated flows fail (Hypothesis)

[SP-initiated flow]

1. User accesses the portal URL.
2. AWS (SP) generates a SAMLRequest.

→ At this stage, AWS determines which ACS endpoint (IPv4 or dual-stack) it expects the response on and includes this in the request.

3. Google responds in accordance with that request.
4. Endpoint consistency is guaranteed. ✅

[IdP-initiated flow]

1. Google independently generates a SAMLResponse. (No prior request from AWS = unsolicited)
2. Google performs a POST to the ACS URL stored in its SAML app configuration (only one type—either IPv4 or dual-stack).
3. AWS's internal validation logic cannot pre-determine which endpoint family the request should arrive on, leading to a potential mismatch during validation. ⚠️

This aligns with the fact that you experienced the same failure when testing with both IPv4-only and dual-stack ACS URLs, and that no events were recorded in CloudTrail (indicating the request was rejected before reaching the logging stage). Additional troubleshooting steps to try:

1. Check the Google Admin Console audit logs

Even if no logs appear on the AWS side, a record may exist on the Google side:

Google Admin Console → Reports → Audit and investigation → SAML (select from the left-hand menu) → Search for events around the time of the failure

Google may record specific error details here (e.g., destination mismatch, certificate issues, etc.).

2. Standardize Identity Center SAML settings to a single endpoint

On the Identity Center "Authentication" settings screen, explicitly configure the system to use only the IPv4-specific ACS URL and Issuer URL. Then, re-test after ensuring the Google SAML app settings match these exactly (do not switch to dual-stack).

3. Check for the presence of RelayState

Use SAML-tracer to verify whether the SAMLResponse sent by Google during the IdP-initiated flow includes the RelayState parameter. If this parameter is missing or contains an invalid value, Identity Center may fail to process the request, resulting in the same generic error.