1.为什么要用OAuth2.0

在一个单位中，可能是存在多个不同的应用，比如汽车制造企业会有财务的系统，4S店的销售系统，面向车主的论坛系统，还有ERP、OA、CRM系统等等，如果每个系统都用独立的账号认证体系，会给用户带来很大困扰，也给管理带来很大不便。所以需要设计一种统一登录的解决方案。比如我登陆了百度账号，进贴吧时发现已经登录了，进糯米发现也自动登录了。

常见的有两种情况：

1）多平台登录，效果是可以用一个账号（比如QQ账号）登录多个不同的网站；多个网站多次登录，但是用户名密码一样，只要记住一个用户名密码；

2）SSO（单点登录）效果是一次输入密码多个网站可以识别在线状态；一次登录可以多次访问不同应用系统；

显然大家希望使用第二种方式，更自由更方便，当然安全风险也随之而来，怎么解决既方便又安全的SSO呢，于是OAuth出现了；

OAuth2.0是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。 OAuth 2.0的运行流程，有兴趣的朋友可以查看官方文档 RFC 6749。

2. OAuth授权码模式认证流程简介

• 授权码模式（authorization code）是功能最完整、流程最严密的授权模式，也是最繁琐最安全的一种模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
• client向资源服务器请求资源，被重定向到授权服务器
• 浏览器向资源拥有者索要授权，之后将用户授权发送给授权服务器
• 授权服务器将授权码转经浏览器发送给client
• client拿着授权码向授权服务器索要访问令牌
• 授权服务器返回AccessToken和RefreshToken给cilent

3. OAuth2.0协议在使用过程中的不规范，容易引起的风险及正确使用的规范

OAuth2.0协议是目前被运用最为广泛的一个SSO协议，在早期的时候爆发过不少相关的安全方面的漏洞，其实仔细分析后会发现大都都是没有严格遵循OAuth2.0的安全相关的指导造成的。

风险1:redirect_url 回调域名欺骗

• 服务端必须验证clientid注册的应用与redirect_url是对应的，否则redirect_url会被伪造成第三方欺诈域名，直接导致服务器返回Code被泄露；
• 服务器生成的临时Code必须是一次有效，客户端使用一次后立即失效并且有效期很短，一般推荐30s有效期，由于Code是通过redirect_url浏览器回调传输容易被截取，可以保证临时Code被客户端正常消费后不会被再次使用

风险2:redirect_url XSS跨域攻击

• 比如构造一个认证请求，redirect_uri = http://app.com/test?callback=<script src="http://app2.com?getToken.php"></script> 服务器端需要对redirect_url进行检查禁止特殊字符输入，并且对redirect_url进行全匹配，不做模糊匹配可以杜绝XSS攻击

风险3:State 防止CSRF

• 认证请求url中state参数是最容易被忽略的，大部分IDP不会强制要求客户端使用state参数；
• 客户端每次请求生成唯一字符串在请求中放到state参数中，服务端认证成功返回Code会带上state参数，客户端验证state是否是自己生成的唯一串，可以确定这次请求是有客户端真实发出的，不是黑客伪造的请求；

风险4:Access_Token泄露

• 由于Access_Token是通过http协议从服务器端传输给客户端，为了防止旁路监听泄露Access_Token，服务器必须提供https来保证传输通道的安全性（TSL的要求）
• 客户端获取Access_Token，应该在后台与服务端交互获取Access_Token，不允许Access_Token传给前端直接使用
• 需要保证Access_Token信息的不可猜测行，以防止被猜测得到；

风险5:令牌有效性漏洞

• 维持refresh_token和第三方应用的绑定，刷新失效机制的设计不允许长期有效的token存在；

4.增强OAuth2.0协议设计及使用规范

OAuth2.0协议安全性进行进一步增强。

• 对颁发出去的token权限进行限制，不同用户申请的token根据人员所属组织、角色、岗位进行数据隔离
• 对登录过程安全性增强，对登录验证方式进行丰富，支持静态密码、手机验证码、OTP、生物识别、FIDO
• 对Token颁发后的生命周期管理，可以按策略主动注销颁发的Token
• 对使用OAuth过程进行行为分析，对登录过程进行风险识别
• 按照不同应用的安全等级进行分级，不同安全级别应用实现二次认证,保障关键系统的安全访问