- 引入refresh_token 是因为 access_token曝光度高看到有人说：对于需要用户登录才能访问的的页面，前端每次访问后端API都要携带access_token(一般放在header中)，所以这就会导致access_token的曝光度比较高，不太安全，所以引入了 refresh_token。但 access_token 通常不是被前端存放在 local_Storage 中吗? 这都不用谈曝光度，别人打开浏览器开发者工具，随时都拿得到啊
- 感觉 access_token 连加密都没必要做个人认为，反正 access_token 要放在前端，也就是随便给人看，那只要 access_token 不放什么敏感信息，即便被不法分子拿到了，他也没啥用啊
因为不法分子拿到token无分是冒充用户身份调用后端API，这个只要后端做了 防重放 和 签名，不法分子就算拿到了token他也很难破这两个点
所以，感觉 access_token 只要不放敏感信息，连加密都没有必要做 - 而有人说，因为refresh_token只是在access_token快过期时才会调用后端API换取新的access_token，曝光度比较低，所以引入了refresh_token!首先，个人认为的流程是：
某次前端调用后端API时，后端告诉前端access_token失效了;
前端然后拿着之前存在local_storage中的 refresh_token再去后端拿一个新的access_token。这样看来，refresh_token 和 access_token 既然都被前端存在 local_storage 中，这曝光度一样样的，没啥区别了，都很容易被不法分子拿到而如果我们将refresh_token放在后端，当access_token过期时，后端帮前端拿到它对应的 refresh_token，然后给它个新的access_token。那还不如别要refresh_token了，后端直接给前端新的acces_token就得了呗。所以这里我想不通，refresh_token到底有什么意义？而且到处都在说 access_token和refresh_token不要曝光，尤其是refresh_token, 也是真没理解啥意思？
所以引入refresh_token 到底是啥原因 没搞懂
回复：你对“非法用户”的理解有误。
你 F12 打开控制台、从 Network 或 LocalStorage 里把 AccessToken 复制出来，然后自己写个爬虫程序开始疯狂调接口。你这在 OAuth 看来其实是正儿八经的“合法用户” —— 这个 AccessToken 本来就是颁发给“你”的，“你”用这个 AccessToken 也没有访问到超越“你”这个用户权限的数据。“你”用了本就属于你自己的 AccessToken 去调接口，这是再“合法”不过的了。
至于你说你绕开了网站本来的业务逻辑，私自发出了请求，那这不是 OAuth 关心的，也不是 OAuth 能解决的问题。那是你自己业务上的“非法”，不是 OAuth 认为的“非法”。
OAuth 想规避的是中间人或者 CRSF 这种的“非法用户” —— 泄露了本不属于他的 AccessToken。其思路很简单，既然泄露不可避免，那就想办法把泄露的损失降低。于是乎就自然而然想到了缩短 AccessToken 有效期的办法。
想一想现实中是不是也是如此？比如你用网银转账，PIN 只有几分钟甚至几十秒的有效期，即便你的 PIN 被坏人偷看到了，他也只能在很短的时间内才能利用上。
但 AccessToken 变短就带来了新的问题：令牌过期了，可正常用户还在用着，总不能没事儿就让用户重新授权吧？于是乎自然而然想到了增加一个 RefreshToken 的方式。
P.S. RefreshToken 并不是解决 AccessToken 有效期变短带来的副作用的唯一方案，甚至 OAuth 2.0 里专门加粗强调了 “However, you may not need refresh tokens”。
非常感谢百忙中抽空回答问题
所以，对于前后端分离的项目，access_token 也都是前端简单做个存储？
如果大家都是这样的话，那泄露确实都不能算是无法避免，而是100%泄露。
面对100%泄露，确实 无论是“合法用户”写爬虫，还是纯粹就是单纯地捣个乱(拿着access_token随便调几个接口)都是问题
既然这样，那业务上我用 “调用频次” 、 “防重放”、 “请求带签名” 这些个策略来作为第一策略，应该可以解决100%泄露的大多数问题。
如果没有上面的第一策略，只是给 access_token 设置个有效期，比如两小时，那在两小时内“合法”用户照样是为所欲为。 而一旦有了上面的第一策略，给access_token设置有效期,…… 又似乎有些多余，因为第一策略已经挡住了“合法”用户。
实际生产中当然是各种安全策略组合来用，越敏感的业务需要的策略就越多。但你所说的其他所有策略，都没有标准可言。而 OAuth 作为一项 IETF 国际标准，是从自身的角度制定了规范，这样它的各种编程语言或框架的具体实现中，才会有一种统一的实现方式。你说纯靠 RefreshToken 能解决百分百的安全问题吗？那肯定是扯淡。但只要你是按 OAuth 标准去实现的，就最起码可以享受到最基本的防护措施，这在很多场景下就足够了。
就比如《GB-21556》这个国标，它规定了我们生活中使用的锁具的安全特征。那符合这个国标的锁具就能完全防住世界上的所有小偷了？那当然不现实。但你说这个国标没用吗？它当然有它的用途。
P.S. 只要你的代码跑在客户端上，就不可能有百分百的安全方案，只有投入产出比的问题 —— 你的网站没什么价值，所以不法分子懒得投入更多的时间去琢磨而已。
另外看问题还要结合历史背景。OAuth 规范提出的时间点，是 2010 年前后，此时的 SSL/HTTPS 普及率相当低，中间人攻击的问题还是相当严重且普遍的。所以 OAuth 中很多跟安全有关的举措，都是为了降低这方面带来的负面影响。但如今随着 SSL/HTTPS 的普及，这其中很多举措确实就显得有些“鸡肋”了，但仍有其存在价值。
