通过CloudFront URL可正常登录EUC仪表板，AWS用户门户登录触发Cognito无效SAML响应错误问题排查

这两种登录方式本质是SAML认证流程中发起方不同，带来了一系列逻辑差异：

• 发起主体不同：
  • CloudFront直接URL登录：属于SP（服务提供商，即Cognito用户池）发起的SAML认证流程。用户访问应用后，Cognito主动重定向到AWS SSO（IdP）请求认证，整个流程的上下文由Cognito把控。
  • AWS SSO用户门户登录：属于IdP（身份提供商，即AWS SSO）发起的SAML认证流程。用户先登录到SSO门户，点击应用后由AWS SSO主动推送SAML断言到Cognito的ACS（断言消费者服务）地址，流程上下文由SSO门户构建传递。
• RelayState的生成逻辑不同：
  • SP发起时，Cognito会自动生成一个合法的RelayState值（通常包含用户后续要跳转的应用地址、会话标识等上下文信息），并传递给IdP；认证完成后，IdP会把这个RelayState原样返回给Cognito，Cognito验证通过后完成跳转。
  • IdP发起时，RelayState需要由AWS SSO负责生成并传递给Cognito。如果SSO配置有误，就会出现RelayState为空的情况。
• 认证上下文的完整性不同：
  • SP发起的流程中，所有必要参数（比如RelayState、ACS地址）都是Cognito预先定义好的，参数缺失的概率极低；
  • IdP发起的流程中，参数依赖SSO应用的配置，一旦配置漏项就会导致认证失败。

你遇到的Invalid_samlResponse_or_relayState_from_identity_provider错误，核心问题就是RelayState为空，结合场景来看，可能的原因有这些：

• AWS SSO应用配置未指定RelayState：
  在AWS SSO中配置Cognito应用时，需要手动指定RelayState参数（通常是Cognito的回调地址或者应用的跳转路径）。如果这一步没配置，SSO在推送SAML响应时就不会携带RelayState，Cognito收到空值后会判定请求无效。
• Cognito对IdP发起的RelayState有格式要求：
  部分情况下，Cognito要求IdP发起的RelayState必须是之前SP流程中生成的有效会话值，或者符合特定格式（比如包含用户池ID、客户端ID等信息）。如果SSO传递的RelayState不符合要求，即使不为空也会报错，更别说空值了。
• SAML响应的其他参数不匹配：
  虽然你提到SAML-Response里有邮箱，但还要检查两个关键参数：
  • Destination：必须和Cognito用户池的ACS URL完全一致（比如https://APP-NAME.auth.eu-central-1.amazoncognito.com/saml2/idpresponse）；
  • Audience：必须设置为Cognito用户池的受众值（通常是urn:amazon:cognito:sp:<用户池ID>）。
    这些参数不匹配时，Cognito也会结合RelayState的问题抛出统一错误。
• AWS SSO与Cognito的SAML配置版本不兼容：
  比如SSO使用的SAML 2.0配置中，是否开启了RelayState传递的选项，或者Cognito是否允许IdP发起的认证请求（有些用户池默认可能限制为仅SP发起）。

内容的提问来源于stack exchange，提问作者decimo