【问题标题】:OAuth2 protected API. How to allow customer's to SSO using its own authorization server?OAuth2 保护的 API。如何允许客户使用自己的授权服务器进行 SSO?
【发布时间】:2021-07-15 21:30:02
【问题描述】:

我有一个 Angular 单页应用程序 (SPA) 与我的 ASP.NET API 通信。 API 受我自己的 Oauth2 服务器 (IdentityServer4) 保护。

我的一个客户(我们称他为 X)想要 SSO:他们在我平台上的用户将在他们的服务器上登录,而不是使用我的应用程序中连接到我的 IdentityServer 的登录表单。

每个客户都有自己的 Angular SPA 子域(例如x.myapp.com)。因此,我可以根据主机名轻松地将 X 的用户重定向到他们服务器的授权页面以批准我的 API。

但是,API 本身为所有客户使用一个通用主机名 (api.myapp.com)。客户在登录调用(和一些其他不受保护的调用)期间通过 API 调用的 Origin 标头 (x.myapp.com) 以及对 API 的受保护调用的 Bearer 令牌进行区分。

  1. 我的 API 如何内省 Bearer 访问令牌?谁应该知道要查询哪个服务器? 是 API 服务器的责任吗?或者我可以告诉我的 IdentityServer X 的 oauth2 服务器吗?

  2. X 的用户也将在我的平台上定义,因为我们需要特定信息(例如平台上的角色配置)。我当前的设置意味着允许我的 API 知道用户可以做什么的特定声明(例如用户 ID)。显然,X 的服务器不会提供相同的声明。如何连接这些点?例如从 X 的服务器获取一些标准声明(用户名、电子邮件等)并将其与我的用户列表相匹配。

注意:This question 类似,但答案不被接受,似乎暗示两个身份服务器的提供者是相同的(这里不是这种情况)。

【问题讨论】:

  • 您是否可以考虑将客户应用作为外部 OpenID 提供者?
  • 我想这是一个选项。我应该问他们
  • 我认为在这种情况下您应该查看的是所谓的联合网关。因此,在您的情况下,您的身份服务器是网关,您的 API 只知道来自它的令牌。然后,您的网关“连接”到所有不同的提供商(google、facebook 等)。登录后,用户将被重定向,您的网关将为该用户创建一个令牌。您的应用程序的其余部分相同。在此处查看此文档:docs.identityserver.io/en/latest/topics/federation_gateway.html
  • 认为您的身份服务器是“协调者”。您甚至可以通过身份服务器上的一些特殊查询参数将用户直接重定向到他们的登录页面,这样他们就不会在那里提示登录,而只会提示他们登录。例如,my-identityserver.com/authenticate?prompt=none&acr_values=idp:customers_ip。 docs.identityserver.io/en/latest/endpoints/…
  • @jpgrassi 感谢您的 cmets。看起来这正是我正在寻找的。顺便说一句,那些 cmets 应该是我可以投票的答案 ;-)

标签: asp.net asp.net-core oauth-2.0 single-sign-on identityserver4


【解决方案1】:

将我的 cmets 格式化为答案:

通过阅读您的问题,我很清楚您可以从所谓的Federated identity 中受益。

正如您所说,您的一位客户想要实现 SSO - 他们希望用户使用他们现有的帐户登录并能够正常使用您的系统。

由于您的域中已经有一个 IdentityServer,您可以做的是将登录部分委派到客户方(无论他们做什么)。这在身份服务器文档Federation Gateway 中有说明。

基本上,该方法是在点击前端的“登录”按钮时,您会将用户重定向到您的身份服务器,并传递一些特殊参数(例如promptacr_values),这反过来又,告诉身份服务器将用户重定向到外部身份提供者(客户的)。成功登录后,您有机会在 Identity Server 中增加声明,可能使用他们返回的内容或其他任何内容。然后该过程正常 - 您返回由 您的身份服务器

生成的 JWT 令牌

这样做的好处是:

  • 您的 SPA/API 不必更改。您仍然可以使用自己的不记名令牌,并且可以像以前一样继续进行 authN/AuthZ。
  • 您有机会添加声明,以表明此用户来自哪里如果需要
  • 如果您客户的服务器发生变化,您不必担心太多,除了可能与退回的索赔相关的一些调整
  • 他们不一定需要自己使用 OpenId/OAuth 才能使其工作

您可能需要的有用的东西是在调用authorize endpoint in Identity Server 期间传递的一些参数。 (acr_valuesprompt)。

您也可以通过查看Sign-in with external providers(与您想要的非常相似)在快速入门中查看这一点

现在谈谈你的个人观点:

  1. 您的身份服务器应该是您与客户的“身份提供商”之间的“桥梁”。

  2. 从外部提供商 (X) 登录后,您需要以某种方式识别您平台上的用户。您可以使用email,或者更好的是,如果X 已经在使用OpenId/OAuth,他们可能会给您sub 声明,这是他们身边的用户ID。在这一点上,您需要与他们达成某种协议,否则这可能对双方来说都是不稳定/不可靠的。

在更“高级说明”中,您还可以在令牌中添加某种声明,告诉您谁是该用户的source provider。这里的源提供者将是 X。这很有用,因为您可能希望,例如,在您的应用程序中配置允许的身份提供者,或者可能只为某些提供者启用功能。例如,使用 Google 登录的用户可能只能看到应用的某些部分。

【讨论】:

  • 非常感谢。非常有帮助。仍然存在灰色区域,但我不相信我会通过挖掘样本来解决它们,因为我现在更好地知道去哪里了。
猜你喜欢
  • 2016-04-10
  • 1970-01-01
  • 2015-07-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-08-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多