【问题标题】:SSO: Authorized Users Management on Google vs. other IdPSSO:Google 上的授权用户管理与其他 IdP
【发布时间】:2019-10-08 08:35:17
【问题描述】:

我的目标是在我的 Web 应用程序中实现 SSO 服务提供者,但我无法理解将 Google 作为身份提供者与其他 IdP 的 SSO。

我创建了两个 POC,一个使用 SAML,另一个使用 OpenID Connect。两者似乎都运行良好。

我注意到,对于我测试过的身份提供程序(OneLogin、Okta),对于两种 SSO 方法(OIDC、SAML),我需要创建一个应用程序并在我的 IdP 上为该应用程序分配授权用户.当用户尝试登录时,只有当他们是授权用户之一时才会成功。这实质上意味着我不必在我的应用程序中管理邀请和授权用户,因为它被委托给身份提供程序上定义的应用程序。

但是,使用 Google 作为 IdP 提供商时,SAML 应用程序没有“分配的用户”部分,而使用 OpenID Connect,我什至不需要创建可以管理用户的应用程序(只需 OAuth 2.0 凭据) .这基本上意味着使用 Google 作为身份提供者,我需要在内部管理授权用户,因为 google 授权任何使用 google 登录并同意共享其个人数据的用户。

如果有人能揭开这种行为的神秘面纱,我将不胜感激。听起来很奇怪,我必须根据我的 IdP 来更改联合身份的授权流程!

【问题讨论】:

    标签: single-sign-on google-workspace federated-identity google-identity google-sso


    【解决方案1】:

    好吧,OIDC 提供的是用户身份验证。 Google 实现仅提供了这一点,而其他一些 IdP 也提供了其他功能。我想说的是,Google 的行为对于开放云提供商来说更为典型(Facebook,虽然他们有自己的基于 OAuth2 的协议,但行为类似),而其他的则更常见于企业内部。

    但是,Google 确实提供了一个名为 hd(用于托管域)的 claim,可用于阻止属于其他域的用户(如果这是您想要的 - 在企业环境中,我会假设是这样)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-09-14
      • 2014-07-19
      • 2017-05-26
      • 1970-01-01
      • 2014-11-08
      • 1970-01-01
      • 2021-03-11
      相关资源
      最近更新 更多