我可以使用授权代码授予与API紧密结合的SPA(我拥有)吗?

use*_*135 1 oauth-2.0 single-page-application auth0

我正在构建一个Angular(版本5)应用程序,它只与一个后端,我的API(Web服务器上的烧瓶应用程序)进行通信,后者又与我的数据库进行通信.该应用程序用于数据输入和可视化,其中数据不断加载并保存到后端或从后端保存.我控制了这三个部分.

我正在考虑使用Auth0来处理身份验证/用户管理.

我的问题是,我可以将此应用程序视为"常规"Web应用程序并使用身份验证代码授予,而不是通常建议用于SPA的隐式授权吗?那是:

  1. SPA将从auth0通过/ login端点获取授权代码,重定向到相应的auth0页面
  2. 授权代码通过某个端点(可能是/ callback端点)传递给API.
  3. API与Auth0交谈以交换交换AC作为令牌.
  4. 每次请求都会将令牌传递给数据库,如果令牌无效,则拒绝令牌(使用postgresql在数据库中进行令牌有效性检查)
  5. API服务器上的令牌与用户之间的关联是通过加密的cookie(Flask的'session'变量)完成的

通过围绕Implicit Grants与Authentication Code Grants的大量讨论,看起来主要区别在于,在真正的SPA应用程序中,没有单一服务器由资源提供者控制,可以存储客户端密钥或令牌.但是,根据我的情况,我不能仅仅将SPA应用程序视为传统(ajax-heavy)网页吗?

我在auth0论坛中发现了这篇帖子,暗示这可能是"脆弱的,因为在实践中你有一个OAuth2流程应由两个独立的组件来处理",但我不明白组件之间的独立性应该如何产生任何差别.

Ján*_*aša 5

是的,您可以使用身份验证代码授权.如果你使用它,有一些设计含义:

  • 您的后端将具有OAuth2客户端的角色,而不是SPA
  • 如果您将令牌从后端传递到SPA并将其用于身份验证(如果您的意思是问题中的第4点),则令牌将在一段时间后过期,用户将不得不再次通过身份验证过程,这可能很烦人.

所以我建议:

  • 要执行身份验证,后端应该有两个端点 - 一个用于重定向到OAuth2服务器,另一个用于接受来自OAuth2服务器的重定向(包含身份验证代码).无需将代码提供给SPA.
  • 后端交换令牌的代码.如果需要,令牌可以保留在后端会话中,或者只是在会话中保留用户信息 - 您可能不再需要令牌.

因此,使用两个授权的主要区别在于,使用隐式授权,您的SPA需要能够在到期之前续订令牌(请参阅OpenID Connect会话管理),并且需要使用身份验证代码授予,后端需要是有状态的 - 到为其客户保持会话.