【问题标题】:SPA + Backend + Office365 SSOSPA + 后端 + Office365 SSO
【发布时间】:2019-12-14 15:46:49
【问题描述】:

我正在构建一个包含以下内容的应用程序

  1. SPA(为用户提供执行操作的前端)- app.myservice.com - React JS

  2. API(提供核心业务逻辑,由SPA调用)-api.myservice.com-Node JS

我想做的是允许人们使用 Office 365“注册”我的应用程序(作为一个整体)。

但是....我希望 API 生成 JWT 令牌,SPA 将来会使用这些令牌与 API 进行通信。我不希望 SPA 具有 Office365 特定令牌。

这个过程在高层次上看起来像这样:

  1. 用户访问 app.myservice.com
  2. 用户点击“注册”
  3. 用户被重定向到 Office365 以提供登录详细信息
  4. Office365 重定向到我的 API
  5. API 在其数据库中创建本地用户
  6. API 生成 JWT
  7. API 将 JWT 返回到 SPA
  8. SPA 使用 JWT 调用 API 来执行操作。

我不清楚要使用什么 OAuth2/OpenID 流类型来实现这一点。

此外,我想了解我的方法总体上是否存在任何缺陷。

非常感谢

【问题讨论】:

    标签: oauth-2.0 openid


    【解决方案1】:

    在上面的第 3 步中,我认为您的 SPA 应该重定向到用户登录的 Azure AD。然后您的 SPA 将收到一个 Azure AD 令牌并将其发送到 API。 API 可能会读取用户信息并在需要时创建用户。 API 不应发布自己的令牌或接收重定向。不确定这是否 100% 满足您的要求,但它是基于 3 腿 SPA 和 API OAuth 2.0 的舞蹈的标准模式。

    【讨论】:

    • 谢谢加里。我已经开始采用你概述的方法。但是,我想了解更多关于您的声明 API 不应发布自己的令牌或接收重定向这是否意味着 API 需要处理从所有 SSO 提供商(Azure、Facebook、谷歌)生成的令牌和它自己的本地数据库)? 拥有一个由 API 生成的单一令牌是否有意义,该令牌抽象出底层提供者(考虑到,用户最终登录并链接到 API 数据库中存在的用户) ?谢谢
    猜你喜欢
    • 2021-05-25
    • 2021-05-24
    • 2019-06-15
    • 2018-04-17
    • 2020-10-25
    • 2021-02-06
    • 2020-01-01
    • 2020-08-26
    • 2018-03-20
    相关资源
    最近更新 更多