带有外部 IdP 的 Okta oauth2

Question

我有一个带有快速服务器的 Angular 应用程序，其中 Okta 充当 IdP。这已经设置并且运行良好。现在，我需要从使用 Amazon Cognito 的外部应用程序支持 SSO。他们通过向我们提供 clientId 和 Secret 为我们的应用启用了 OAuth2 Auth 代码流。

我想了解的是我应该在哪里与 accessTokens 交换 authCode，以及我应该如何为通过 Okta 中的 SSO 来的用户管理会话。我有几个选择：

1. 我在使用“angular-oauth2-oidc”库的 Angular 应用程序中进行了尝试，但在使用 AWS Cognito 调用 /authorize 端点时遇到了 CORS 问题。此外，似乎在前端通道中将 authCode 与 accessToken 交换可能不是最安全的方式。

2. 对于 SSO 用户，我可以在 express 中编写一个新的路由处理程序来管理令牌交换，并将此路由作为对 Cognito 的初始授权调用中的回调 url。但是，我的 express 服务器已经使用“express-stormpath”sdk 来处理我们通常情况下的会话管理，其中 Okta 充当 IdP。如何使用 Cognito IdP 在同一个地方快速管理本地 Okta 用户会话和 SSO 用户会话。

3. 我还尝试将 Okta 联合设置为外部 IdP。但是，我不确定如何将身份验证调用路由到外部 IdP，而 Okta 本身充当我们内部用户的 IdP。

我更倾向于 3，我只与 Okta 交谈，它负责为我们的内部用户 (Okta IdP) 以及来自外部 IdP (Cognito) 的 SSO 用户管理身份验证。

这里的任何帮助将不胜感激..

谢谢， RK

Answer 1

这是一个非常多的问题，但这里有一些提示：

1a。您需要将您的 SPA 域作为可信来源添加到 Okta，如 step 7 of my write up

1b。当您说“不是安全的方式”时，您需要更明确地表达您的担忧以及您的意思。

如果您只是想作为 SPA 与 Okta 集成，请尝试运行我的 initial code sample。

2a。您需要根据自己的目标制定策略。我个人对 SPA 最佳整体架构的看法总结在下面的博文中，但这里有很多要理解的地方，有些人可能会有不同的看法：

• Architecture Goals
• Access tokens in the browser
• Refresh tokens in cookies

2b。如果您正在构建 SPA，您可能应该避免使用旧的 Web 后端会话管理功能，尽管有些人会使用它们。

3a。我同意你的观点，这是首选。旨在构建您的应用程序，以便它使用来自一个提供商的令牌，而不管登录方法如何。

3b。当您重定向到 Okta 时，您需要执行以下操作之一：

• 在构建授权请求时向 Cognito 颁发者 ID 发送 idp parameter
• 配置 Okta 以提示用户输入登录方法，以便 Okta 或 Cognito 可以用作身份提供者。在 Okta 中配置 idp 连接后，默认情况下可能会发生这种情况。

联邦截图

我对此进行了快速浏览，我并不是说它会很容易，甚至可能，因为遇到供应商限制是很常见的。但是，这就是该技术应该如何工作的方式。这种复杂性最好存在于授权服务器中而不是您的应用程序代码中。

在 Cognito 中创建 OAuth 客户端：

然后从如下 URL 获取 Cognito 的元数据：

• https://cognito-idp.eu-west-2.amazonaws.com/eu-west-2_qqJgVeuTn/.well-known/openid-configuration

然后填写 Okta 需要的端点：

这将生成 IDP 值并为您提供重定向 URL：

然后在Cognito中输入生成的值，完成配置：