令牌的无状态性和存储 [英] Tokens statelessness and storage

查看:137
本文介绍了令牌的无状态性和存储的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经读了很多关于不将令牌保存在用户代理存储中的内容,并且我同意所提到的风险. 但是,通过一些Auth0快速入门示例,我看到令牌已保存在会话中,并使用会话cookie来跟踪它们.

I have been reading a lot about not saving the tokens in the user agent storage and I agree with the risks mentioned. But going through some of the Auth0 quickstart examples, I see the tokens being saved in the session and using session cookies to track them.

其他人提到以较低的风险将实际令牌保存为httpOnly cookie.

Others mention saving the actual token as an httpOnly cookie with lower risks involved.

我的问题是:

  • 如何将其视为无状态?特别是在可伸缩性和负载平衡器的潜在用途方面.
  • 替代品,内存缓存和数据库存储吗?与会话有什么不同吗?
  • 对于SPA,如何保持记住我的功能?

推荐答案

Asi Kavindu写道,localStorage是个好地方.如果您想保护应用程序不受XSS攻击,请使用内容安全策略,因此浏览器仅执行您的JavaScript代码.最近有关于 OAuth 2.0和基于浏览器的应用,因此您可以对其进行检查.

Asi Kavindu wrote, localStorage is a good place. If you want to protect the application against XSS attacks, use Content Security Policy, so a browser executes only your JavaScript code. There is a recent RFC about best practices for OAuth 2.0 and Browser-Based Apps, so you can check it.

如果要在具有多个后端节点(群集)的后端上保持状态(会话),则可以使用某些共享数据存储,例如数据库或Hazelcast.该架构具有状态性,就像具有内存会话的单个后端节点一样.

If you want to keep state (session) on your backend with multiple backend nodes (cluster), you can use some shared data storage such as database or Hazelcast. The architecture is stateful in the same way as a single backend node with an in-memory session.

如果您的后端有一个会话和一个cookie,则不再需要访问令牌,因为yor SPA只会调用您的后端,并且令牌的作用与cookie中的会话ID相同.

If you have a session on your backend and a cookie, you don't need an access token anymore, since yor SPA calls just your backend and the token would serve the same purpose as the session ID from the cookie.

记住我"功能可以在您的身份验证提供者(从安全性的角度来看可能是更好的选择)中使用cookie来实现,也可以在您自己的应用程序中实现.

The remember me functionality can be implemented using a cookie either at your authentication provider (probably better choice from the security standpoint) or your own application.

架构选择通常是在简单性和可伸缩性之间进行权衡.如果您只是开始开发应用程序而不确定要选择什么,那么我会为了简单起见,因为即使您以后要更改它,重构起来也应该更容易.

Architecture choices are usually trade-offs between simplicity and scalability. If you are just starting developing the application and not sure what to choose, I would go for simplicity, because even if you want to change it later, it should be easier to refactor.

这篇关于令牌的无状态性和存储的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆