SPA认证

Question

我正在为我的公司开发一个具有以下参数和组件的应用程序：

• 第一党正面单页申请(SPA)。这是用TypeScript (JavaScript的方言)实现的，我们正在内部开发代码。
• 第一党后端REST，它允许访问位于其他地方的MongoDB。这是在JavaScript中实现的，并使用在Node上运行的Express。我们正在开发内部代码。现在，这个部分所做的就是通过REST提供CRUD操作。
• 这些申请只适用于我们的雇员。所有员工都有Windows 10笔记本电脑，这些笔记本电脑已经加入了我们公司的Azure广告。
• 我们没有一个内置的ADFS服务器.我们是100%的云。
• 应用程序将在其业务逻辑(如Graph )中使用Azure资源。
• 该应用程序还将使用其他第三方资源，如我们的公司Dropbox。
• 对“应用程序”的身份验证也应尽可能无缝地针对所有其他第三方应用程序(如Dropbox)进行身份验证。
• 今天我们有10名员工。这是非常不可能的，我们将有超过50名雇员在未来几年，当这个应用程序将转到版本2，我将聘请一个人来建造它。

现在是为应用程序实现身份验证和授权的时候了。应用程序应该同时对Azure AD进行身份验证和授权。理想的情况是，登录到公司笔记本电脑的用户应该在应用程序上进行自动魔术认证，而另一台计算机(比如机场或旅馆亭)的用户可以使用他们的Azure AD凭据登录。

我的问题是在这个场景中应该使用什么OAuth2授权流。

我读过许多来自微软和OAuth的文章，浏览了许多Udemy类等等，并从这些来源得到了相互矛盾的建议。一些人建议SPA应该使用隐式授予，而另一些人则认为，如果后端服务器上有业务逻辑(并且存在/将存在)，则应该使用客户端凭据授予。

我是一个非常有经验的开发人员，但我不是安全专家。在我的完美世界里，我会把这个应用程序的认证部分的设计和实现外包给一个安全专家，但是预算是这里的一个主要限制。这是根本不可行的花费数千美元，让人为我们建设这一阶段。

尽管如此，鉴于上述设计和体系结构，应该如何实现身份验证？应该使用哪一种授权流？

Answer 1

医生含蓄的..。检查我应该使用哪个OAuth2.0流？以获得决策过程的可视化。

当涉及到认证时，魔鬼在细节上.我尽量别忘了任何东西。

基本OAuth2规范引入了四种授予类型：

• 隐性赠与
• 授权代码授予
• 客户凭据授予
• 资源所有者密码凭据(ROPC)授予

如果不包括ROPC，它为用于存储用户名和密码的应用程序提供无缝迁移路径，以便能够代表用户行事，那么您将得到三种可能的授权。

在这三种授权中，您明确区分了客户端凭据(CC)授予和其他两种授权。CC授予是针对希望代表自己访问资源的客户端应用程序，即具有客户端应用程序本身的标识的客户端应用程序。

这意味着，为了使用此授权，客户端应用程序必须能够执行客户端身份验证，以证明请求来自合法应用程序。

SPA无法执行客户端身份验证，因为您存储在应用程序中作为身份验证手段的任何秘密密钥都将对希望查看源代码的任何人可见。然后，CC授权主要限于服务器端应用程序，在这些应用程序中，保密更容易。

另一个要点是，如果您希望您的客户端应用程序访问最终用户拥有的资源和/或代表他们执行操作，那么CC授权是不适用的。

现在看来，选择池是我们开始使用的一半，其余的候选项是隐式或授权代码授予。通常，如果您有SPA，则执行需要身份验证/授权的请求的代码在浏览器端，因此显而易见的选择是隐式授予，因为它将令牌作为授权端点响应的一部分来传递，并且不需要向令牌端点追加请求，而在浏览器-land中，该请求可能表示一个CORS请求，而这个请求可能可行，也可能不可行。

另外，如果您所描述的组件(前端SPA和后端API)被视为生活在同一域下的单个应用程序，而不打算向其他应用程序开放API，那么甚至可以依赖传统的基于HTTP的基于cookie的身份验证，根据OpenID连接规则接收ID令牌来引导它。您提到了REST，因此只想声明基于cookie的身份验证不一定意味着服务器端托管会话；然而，基于cookie的身份验证需要CSRF缓解。