首页 文章

在OAuth2中混合授权代码和隐式授权类型

提问于
浏览 次
0

我对涉及OAuth2的以下流程有一些疑问：

webapp1.xyz.com是具有授权代码授权类型的注册客户端，这是当前流程：

  • 用户登录并使用授权码重定向到webapp1.xyz.com

  • webapp1.xyz.com交换访问令牌的授权码并将其存储到会话中

  • webapp1.xyz.com服务器端需要通过传递访问令牌来调用webapp2.xyz.com api

  • webapp1.xyz.com有SPA，其中ajax调用webapp1.xyz.com api endpoints （在请求中传递会话cookie）

  • 用户注销，会话被销毁

有人建议使用（隐式授权）访问令牌而不是会话cookie来进行ajax调用 . 甚至可能混合授权代码和隐式授权类型？也许我正在混合一些东西，我看不出为什么在ajax部分使用隐式授权类型的原因 .

javascript ajax oauth oauth-2.0 single-page-application

1 回答

  • 2

    甚至可能混合授权代码和隐式授权类型？

    问题更多的是你在谈论两个应用程序的一个令牌 . 或者更确切地说，webapp1既是OAuth客户端（调用Web API的网站 - webapi2），也是OAuth资源（SPA可以使用隐式授权调用的Web API） .

    所以：SPA javascript> webapp1.xyz.com应用程序> webapp2.xyz.com应用程序 .

    在Oauth2.0术语中，您的SPA客户端应用程序将是客户端，而webapp1和webapp2将是资源 . 理想情况下，客户端将使用隐式授权来获取访问令牌，因为这是公共JavaScript客户端的优化流程 .

    如果可能，可以查看混合流 - OAuth2和OpenID Connect - 而不是授权代码流 .

    使用混合流程，webapp1将获得当前的令牌，但它也将获得一个ID令牌，它可以传递回SPA .

    ID令牌旨在供客户端用于身份验证 - 此ID令牌可以执行会话cookie正在执行的相同工作（即SPA和SPA后端之间的身份验证） . 并且访问令牌将安全地存储在远离SPA的webapp1服务器上 .

    回复于

相关问题