我们有一个用 ASP.NET MVC 编写的应用程序，它由 Web（非 rest，使用 razor）和 API 项目（以及一些其他项目，但现在不重要）组成。
Web 中的身份验证使用基本表单身份验证完成，API 中的身份验证使用 OAuth2 完成。
事实证明，在同一个应用程序中使用两种身份验证方式有点难以维护，因此我们决定放弃表单身份验证，并将 OAuth2 用于 Web 和 API 项目。
在 Web 项目中，我们可能不得不将 OAuth2 令牌存储在 cookie 中，而不是将它们作为标头发送。是否可以使用 OAuth2 来保护“非休息”应用程序？如果是这样，这样做是否存在一些安全问题？
【问题讨论】：
标签： asp.net asp.net-mvc rest authentication oauth
有一些关于您感兴趣的主题的优秀文章。这些文章解释了您正在寻找的详细信息。
这些网站将是起点。 OAuth 2.0 饱受诟病，但大家指出的安全漏洞在其他身份验证模型中也很常见。因此，如果在应用程序中解决了这些漏洞，那么安全问题就会自行缓解。
但也必须注意，OAuth2 并不是 OAuth1 的下一代。你可以找到一篇优秀的文章here。
【讨论】：
直接的答案是，是的，依赖 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/会话和令牌身份验证的进一步阅读资源，可以帮助您获得一些不同的观点来支持决策过程：
【讨论】：