访问令牌和刷新令牌的最佳做法?如何实施访问与控制刷新令牌 [英] Access token and Refresh token best practices ? How to implement Access & Refresh Tokens
问题描述
我正在制作SPA，并决定使用JWT进行身份验证/授权，并且我读了一些有关令牌与Cookie的博客.我了解Cookie授权的工作原理，并了解基本令牌授权的工作原理.问题是，我看不到刷新令牌如何适合它，对我而言似乎降低了安全性.让我来解释一下，
Cookie方法
通过用户名&验证用户身份时密码，您将创建与该用户关联的会话ID.并将其设置为cookie，每次客户端调用您的服务器时，它都会发送该cookie，服务器可以在数据库或其他服务器端存储中查找关联的用户.
-
这种方法容易受到CSRF(跨站点请求伪造)的攻击.要防止CSRF，您可以将令牌与cookie一起使用
-
服务器还需要不断查找存储以查看Cookie指向的用户.
令牌方法
通过用户名&验证用户身份时密码，您将创建一个签名的令牌，并在有效载荷中包含到期日期，电子邮件地址或用户ID，角色等.为了安全起见，令牌应具有较短的到期时间.令牌可以存储在本地存储，会话存储，cookie的任何位置.我将使用本地存储或会话存储来防止XSRF.
- 这容易受到XSS(跨站点脚本)的影响，但是您可以通过验证HTML输入来防止这种情况.
- 由于令牌的生命周期较短，因此令牌到期后，用户必须再次登录.
访问令牌&刷新令牌
因此，我想使用刷新令牌来防止用户需要不断登录.因此，可以说在身份验证上，我给了用户访问令牌和刷新令牌，当用户访问令牌过期时，用户可以使用刷新令牌来获取新访问令牌，这是我没有得到的.
- 让我说我将访问令牌存储在本地存储中.如果我还将刷新令牌存储在本地存储中，则看不到有任何用处.因为如果攻击者可以访问本地存储并获取访问令牌，那么他也可以获取刷新令牌.因此，在这种情况下，为什么不只是让Access令牌长期存在呢?
- 如果将刷新令牌存储为cookie，则XSRF容易受到攻击，然后攻击者可以获得新的访问令牌并使用它.同样在这一点上，为什么不仅仅使用Cookie授权呢?因为您已经必须在本地存储中查找刷新令牌，但是这种情况的发生频率要比纯cookie授权少.
最佳做法是什么?
目前我正在考虑使用:
- 访问令牌(本地存储，寿命短)
- 刷新令牌(Cookie，万岁)
- 用于刷新令牌的令牌(为防止XSFR，本地存储，在使用一次后失效)
让我们说它看起来像这样:
+ -------- + + --------------- +|| ------------授权拨款---------> ||||||||< ---------------访问令牌------------- ||||&刷新令牌(cookie)||||&XSRF令牌|||||||||||| ---------访问令牌-------------------> ||||||||< -----受保护的资源----------------- |||客户||服务器||| ---------访问令牌-------------------> ||||||||< -----无效的令牌错误---------------- |||||||||||| ----------------刷新令牌-----------> ||||&XSRF令牌||||||||< ---------------访问令牌------------- ||||&XSRF令牌||+ -------- +&可选的刷新令牌+ ----------------- + 每次使用刷新令牌时，服务器都会发行新的XSRF令牌(使用了一个XSRF令牌后，它将停止工作，服务器会发行新的XSRF令牌).您对该实现有何看法?在我看来，这限制了服务器对数据库的查找，因为它使用访问令牌，访问令牌是短暂的，并且由于使用刷新令牌，用户不必经常登录/cookie女巫受到XSRF令牌的保护.
可以吗?
谢谢！
关于访问令牌和刷新令牌
将访问令牌视为脏"访问令牌.令牌.您共享的令牌很多.我不必是将令牌传递到的一台服务器，可以很多.因此，攻击面上升.如果一台服务器做一些愚蠢的事情，例如将令牌写入服务器日志，然后再将日志公开，那么您希望限制负面影响，因此访问令牌的寿命很短，以限制攻击者执行恶意操作的时间.另一方面，刷新令牌是干净的"令牌.令牌.您存储的东西仅供您记住并仅在必要时使用.当然，如果攻击者获得了对您的计算机和用户代理的物理访问权，那么游戏就结束了.但是在这里，我们尝试保护免受远程攻击者的侵害.仅当与身份验证服务器或身份验证端点对话时，才应使用刷新令牌.如果您决定将其设置为cookie，则可以-只需记住将目录路径限制为仅令牌要传递到的REST端点即可.
关于您的解决方案
在我看来不错.也许我不会仅仅为了节省精力而实现XSRF令牌.我的意思是，如果有人尝试对CSRF进行攻击，最糟糕的事情是什么?他也许可以使您刷新令牌.但是令牌不会仅由于CSRF而暴露给攻击者.
还有一件事
我喜欢你的问题.真的写得很好！:)
I'm making SPA, and decided to use JWT for Authentication/Authorization, and I have read some blogs about Tokens vs Cookies. I understand how cookie authorization works, and understand how basic token authorization works. The problem is, I don't see how refresh token fits into it, seems to me it decreases security. Let me explain, as I see it:
Cookie approach
When you authenticate user via username & password, you create session ID associated with that user. And set it as cookie, every time that client calls to your server it sends that cookie, and server can look up associated user in database or some other server side storage.
This approach is vulnerable to CSRF (Cross Site Request Forgery) To prevent CSRF You can use tokens with cookie
Server also needs to constantly look up storage to see to what user, the cookie points.
Token approach
When you authenticate user via username & password, you create a signed Token, with expiration date, email address or userID, role, etc. in payload. For security tokens should have short expiration time. Tokens can be stored anywhere Local storage, Session storage, cookies. I will be using local storage, or session storage, to prevent XSRF.
- This vulnerable to XSS (Cross Site Scripting), but you can prevent this by validating HTML input.
- Because tokens have short lifecycle, user must login again, when token expires.
Access Token & Refresh Token
So I want to use Refresh tokens to prevent user from needing to login constantly. So lets say on Authentication, I give user Access token and Refresh token, when users Access token expires, user can use Refresh token to get New Access token, This is what I don't get.
- lets say I store access token in local storage. If I also store Refresh token in local storage, I don't see any use for it. Because if attacker can access local storage and get Access token he can also get Refresh token. So in this case why not just make Access token long lived.
- If you store Refresh token as a cookie, it is vulnerable to XSRF, and then attacker can get new access token, and use that. Also at this point, why not just use Cookie authorization ? Because you already have to look up local storage to for refresh token, though this will happen less frequently than with pure cookie authorization.
What's the best practice ?
Currently I'm thinking about using:
- Access Token (local storage, short lived)
- Refresh Token (Cookie, Long lived)
- Token for Refresh Token (To protect against XSFR, Local storage, expires after one use)
Let's say it looks like this:
+--------+ +---------------+
| |------------ Authorization Grant --------->| |
| | | |
| |<--------------- Access Token -------------| |
| | & Refresh Token (cookie) | |
| | & XSRF Token | |
| | | |
| | | |
| |--------- Access Token ------------------->| |
| | | |
| |<----- Protected Resource -----------------| |
| Client | | Server |
| |--------- Access Token ------------------->| |
| | | |
| |<----- Invalid Token Error ----------------| |
| | | |
| | | |
| |---------------- Refresh Token ----------->| |
| | & XSRF Token | |
| | | |
| |<--------------- Access Token -------------| |
| | & XSRF Token | |
+--------+ & Optional Refresh Token +---------------+
Server would issue new XSRF Token every time Refresh token is used(after one XSRF token is used it stops working and server issues new one). What you think about this implementation ? In my eyes this limits server lookups to database, as it uses access tokens, access tokens is short lived, and user don't have to login constantly as it uses refresh token/cookie witch is protected by XSRF token.
Is this OK ?
Thanks !
Regarding access token and refresh token
Consider the access token to be a "dirty" token. Token you share a lot. I does not have to be one server you pass the token to, can be many. Because of this the attack surface rises. If one server does something stupid like writing tokens into server logs and then exposing the logs to the world, you want to limit the negative impact, therefore the access tokens are short lived, to limit the time the attacker can do something malicius.
On the other hand a refresh token is a "clean" token. Something you store for yourself to remember and use it only if you must. Of course if the attacker gains physical access to your computer and the user agent, then it is game over. But here we try to protect from the remote attacker. The refresh token should only be used when talking to an auth server or an auth endpoint. If you decide to make it a cookie - you can - just remember to limit the directory path to just the REST endpoints the token is to be passed to.
Regarding your solution
It looks good to my eye. Maybe I would not implement the XSRF Token just to save effort. I mean, what is the worst thing that can happen, if someone tries to attack over CSRF? He might be able to make you refresh your token. But the token will not be exposed to the attacker only because of CSRF.
One more thing
I like your question. It is really well written! : )
这篇关于访问令牌和刷新令牌的最佳做法?如何实施访问与控制刷新令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
