技术干货 | OAuth2.0的安全解析
Posted 信息安全洞察
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了技术干货 | OAuth2.0的安全解析相关的知识，希望对你有一定的参考价值。
//
在一个单位中，可能是存在多个不同的应用，比如汽车制造企业会有财务的系统，4S店的销售系统，面向车主的论坛系统，还有ERP、OA、CRM系统等等，如果每个系统都用独立的账号认证体系，会给用户带来很大困扰，也给管理带来很大不便。所以需要设计一种统一登录的解决方案。比如我登陆了百度账号，进贴吧时发现已经登录了，进糯米发现也自动登录了。
常见的有两种情况：
1）多平台登录，效果是可以用一个账号（比如QQ账号）登录多个不同的网站；多个网站多次登录，但是用户名密码一样，只要记住一个用户名密码；
2）SSO（单点登录）效果是一次输入密码多个网站可以识别在线状态；一次登录可以多次访问不同应用系统；
显然大家希望使用第二种方式，更自由更方便，当然安全风险也随之而来，怎么解决既方便又安全的SSO呢，于是OAuth出现了；
OAuth2.0是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。OAuth 2.0的运行流程，有兴趣的朋友可以查看官方文档RFC 6749。
授权码模式（authorization code）是功能最完整、流程最严密的授权模式，也是最繁琐最安全的一种模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
client向资源服务器请求资源，被重定向到授权服务器；
浏览器向资源拥有者索要授权，之后将用户授权发送给授权服务器；
授权服务器将授权码转经浏览器发送给client；
client拿着授权码向授权服务器索要访问令牌；
授权服务器返回AccessToken和RefreshToken给cilent。
OAuth2.0协议是目前被运用最为广泛的一个SSO协议，在早期的时候爆发过不少相关的安全方面的漏洞，其实仔细分析后会发现大都都是没有严格遵循OAuth2.0的安全相关的指导造成的。
服务端必须验证clientid注册的应用与redirect_url是对应的，否则redirect_url会被伪造成第三方欺诈域名，直接导致服务器返回Code被泄露；
服务器生成的临时Code必须是一次有效，客户端使用一次后立即失效并且有效期很短，一般推荐30s有效期，由于Code是通过redirect_url浏览器回调传输容易被截取，可以保证临时Code被客户端正常消费后不会被再次使用；
风险2:redirect_url XSS跨域攻击
比如构造一个认证请求，redirect_uri = http://app.com/test?callback=<script ></script> 服务器端需要对redirect_url进行检查禁止特殊字符输入，并且对redirect_url进行全匹配，不做模糊匹配可以杜绝XSS攻击；
认证请求url中state参数是最容易被忽略的，大部分IDP不会强制要求客户端使用state参数；
客户端每次请求生成唯一字符串在请求中放到state参数中，服务端认证成功返回Code会带上state参数，客户端验证state是否是自己生成的唯一串，可以确定这次请求是有客户端真实发出的，不是黑客伪造的请求；
由于Access_Token是通过http协议从服务器端传输给客户端，为了防止旁路监听泄露Access_Token，服务器必须提供https来保证传输通道的安全性（TSL的要求）；
客户端获取Access_Token，应该在后台与服务端交互获取Access_Token，不允许Access_Token传给前端直接使用；
需要保证Access_Token信息的不可猜测行，以防止被猜测得到；
维持refresh_token和第三方应用的绑定，刷新失效机制的设计不允许长期有效的token存在；
4.派拉软件增强OAuth2.0协议设计及使用规范
派拉软件专业做身份管理，对OAuth2.0协议进行深入研究，并且对其安全性进行进一步增强。
对颁发出去的token权限进行限制，不同用户申请的token根据人员所属组织、角色、岗位进行数据隔离；
对登录过程安全性增强，对登录验证方式进行丰富，支持静态密码、手机验证码、OTP、生物识别、FIDO；
对Token颁发后的生命周期管理，可以按策略主动注销颁发的Token；
对使用OAuth过程进行AI人工智能行为分析，对登录过程进行风险识别；
按照不同应用的安全等级进行分级，不同安全级别应用实现二次认证,保障关键系统的安全访问。
以上是关于技术干货 | OAuth2.0的安全解析的主要内容，如果未能解决你的问题，请参考以下文章