我将构建一个Web服务，其中包含通过RESTful API公开的所有资源。我将拥有自己的用户数据库，他们访问网络服务的主要方式是通过我也会写的网站。该网站将包含HTML页面和JavaScript，它们将调用API。
还有第三方应用程序可以访问API，因为用户通过我的授权服务器授权他们（我计划在物理上与API服务器相同）。因此，使用OAuth 2.0似乎非常适合。
为了降低复杂性并提高可维护性，我想以与处理身份验证和授权方面的第三方应用相同的方式对待自己的网站。
然而，这引起了一些我迄今无法满意的担忧。以下问题涉及我的网站，而不是第三方应用程序，因为他们实际上在我看来会有一个更简单的工作。使用OAuth意味着在每个请求中附加访问令牌。我可以通过让用户提供他的用户名和密码并使用implicit grant流来获取访问令牌。但
隐式授权不支持刷新令牌的发布。因此，我将强制用户不时再次登录，破坏用户体验或发出访问令牌将具有真正长的有效期。
JavaScript应用必须将访问令牌存储在某处。我没有这方面的经验，但我假设使用会话或本地存储来实现这一目标。但是如果攻击者获得对用户浏览器的访问权限，他可以自己发送有效的API请求，因为他可能会读取访问令牌。 CSRF prevention measures是否足以避免这种情况？或者我应该放弃并假设一旦有人获得用户浏览器的访问权限，所有地狱都会破裂，没有必要以任何额外的方式解决这一威胁？
在过去的几天里，我已经阅读了很多关于这一点的内容，我对信息感到不知所措，无法让我明白解决方案。如果我最终不必支持第三方应用程序，我可能只需要设置一个Forms身份验证cookie，客户端会自动将其附加到每个请求，这就是它。但是我不希望有双重逻辑来验证请求（访问第三方应用程序的令牌和我自己网站的cookie）。
有人discourage the implicit grant altogether ...
请请尽量避免隐含授权，这对每个人来说都是一个伤害，如果您对用户体验和安全性稍微关注，那就不值得实施。
......这进一步增加了我决定的不确定性。
当然，所有通信都只使用HTTPS。
修改：关于如何使用OAuth保护API的official ASP.NET tutorial也使用上述网站流程（除了他们使用“密码”授权类型而不是“隐式” “一个人，所以也许我正在思考这个问题，应该走这条路。