#oauth2 #authorization
前些日子尝试在公司实现了基于OAuth 2.0授权码模式的认证流程。流程有些复杂，但成功实现之后的效果还挺不错的。
这里也不记录具体流程，只说一下踩的一些坑。scope难以确定#
因为用户体系还是使用RABC的经典权限控制，我至今也没有想清楚scope和RABC怎么结合比较合理，以至于这个参数的意义几乎等于没有。
有一种说法是一个 API 就对应一个 scope ，其实也有一定道理，实际操作上应该如何实现还有待研究。登出的问题#
用户在子系统登出时仅丢弃了JWT，导致再次点击授权就会直接登录先前的账号，这使得在同一台设备上没法更换账号。为此我们选择在授权时增加了一个确认操作，用户可以在这一步手动选择更换账号。然而体验上总觉得不是很好……参数中的state有什么用#
state参数在OAuth 2.0中是可选的，它用于防止CSRF攻击。
state参数是由客户端生成的随机字符串，它在进行OAuth 2.0授权请求时附加在授权服务器的重定向URL中。当用户被重定向回客户端后，客户端接收到授权服务器返回的授权码或访问令牌时，会同时返回带有相同state值的参数。
客户端在接收到带有state参数的回调请求后，应该验证state参数的值是否与初始请求中生成的值相匹配。如果不匹配，则可能受到CSRF攻击，应该拒绝处理该请求。
通过使用state参数，客户端可以确保授权流程中的每个请求都是由合法的用户发起的，从而增加了安全性。Refresh Token 和 Access Token#
Refresh Token 和 Access Token 拥有完全不同的职责，需要注意的是 Refresh Token 要被设置为不能用于访问资源，否则由于其有效时间较长，泄露会造成很大影响。