我们有一个用ASP.NET MVC编写的应用程序，它包含Web（非休息，使用razor）和API项目（以及其他一些项目，但现在除此之外）。
Web中的身份验证使用基本表单身份验证完成，API中的身份验证使用OAuth2完成。
在同一个应用程序中有两种身份验证方式已经证明有些难以维护，因此我们决定放弃表单身份验证并对Web和API项目使用OAuth2。
在Web项目中，我们可能必须在Cookie中存储OAuth2令牌，而不是将其作为标头发送。是否可以使用OAuth2来保证＆＃34;非休息＆＃34;申请？如果是这样，这样做会有一些安全问题吗？
答案 0 :(得分：0)
有一些关于您感兴趣的主题的优秀文章。这些文章解释了您正在寻找的细节。
这些网站将成为起点。 OAuth 2.0受到了很多批评，但每个人都指出的安全漏洞在其他身份验证模型中也很常见。因此，如果在应用程序中解决了这些漏洞，那么安全问题将会自行缓解。
但必须注意的是，OAuth2不是下一代OAuth1。你可以找到一篇优秀的文章here。
答案 1 :(得分：0)
直接的答案是，是的，依靠OAuth 2.0是可能的，但是，最诚实的答案是它取决于它并且有多种方法可以做到。
如果您的Web应用程序完全独立且不作为API的客户端，我个人的倾向是使用OAuth 2.0 / OpenID Connect流程来获取用户身份验证，接收证明其身份的令牌然后创建基于cookie的常规会话。当我说常规会话时，我的意思是存储在服务器端的会话，而cookie只包含该会话的唯一标识符。
您也可以继续将实际令牌存储在cookie中并且无状态，但老实说，我没有看到好处。在大多数情况下，Web应用程序将希望在会话中存储足够的信息，以便将其全部保存在cookie中，这一点很简单。是的，您可以保存访问令牌，然后在与该令牌关联的服务器端仍然具有会话状态，但是您将从保存实际令牌中获得什么。
在这种情况下，事情可能会有所不同。从您的问题来看，您的Web应用程序基于ASP .NET MVC，因此我假设API调用将在服务器端进行。
我仍然会在验证时在Cookie中创建常规会话标识符，而不是保存实际令牌，但更重要的是，您必须决定令牌过期时该做什么 ，你可以让应用程序会话尽可能与令牌允许一样多，然后强制用户重复整个身份验证过程以获取新令牌，但除非你的访问令牌有很长的生命周期（通常不赞成，不常见）并且也不推荐）这对用户体验非常不利。
我倾向于使用会话标识符而不是令牌本身只是因为承载令牌，如果它不是功能要求让令牌可用于客户端然后不这样做，否则你就是只是增加了违规情况下的影响。
就个人而言，在这种情况下，我会求助于OAuth refresh token支持，以便在用户会话处于活动状态时继续刷新Web应用程序访问令牌。通过这种方式，您可以轻松实现一个活动的滑动会话，只要用户同时使用具有较短生命周期的访问令牌，从而减少访问令牌泄露的影响。
以下是有关进一步阅读有关cookie /会话和令牌认证的一些资源，可帮助您获得一些不同的观点来支持决策过程：