Oauth2.0协议及安全性改进

一、Oauth介绍

摘录几篇网友的总结：
1.OAuth 白话简明教程－简述
2.OAuth2.0 介绍
3.帮你深入理解OAuth2.0协议

二、个人理解

在整个Oauth认证流程过程中，共有两次重定向(即302、response.redirect)，第一次是用户访问子系统的URL，由子系统重定向到SSO服务器进行认证；第二次重定向是由SSO服务器在第一次重定向的基础上产生一次性授权码authorization_code之后，需要将授权码authorization_code通过用户浏览器重定向返回给子系统。
即：第一次重定向的目的是引导用户去SSO服务器上进行认证并产生code；sso产生的code需要“告知”子系统，因此才有了第二次重定向，在用户通过浏览器提交用户名密码至sso及sso产生code的整个过程，子系统并未参与(只有浏览器和SSO在交互)，因此sso产生的code需要借助于浏览器重定向到子系统，以此来告知子系统code。通过这两次重定向后子系统就已经获得了code，之后子系统通过http协议用code换取access_token，在这一过程中(子系统用code换取access_token)，浏览器并未参与而是直接server(子系统)到server(SSO)，这样在一定程度上就能保证了access_token的安全性。

三、安全性及未来改进

1.授权码authorization_code是如何保证安全性的，即如果authorization_code被截取后果如何？authorization_code的安全性由Oauth协议来保证(state状态码的作用)，详情可查阅Oauth的文档；
2.access_token虽然是server到server间的调用，但也不排除在子系统和SSO之间被截获的可能性，因此安全改进措施之一就是对access_token进行https加密传输；
3.在Oauth2.0协议中，回话的保持是基于Session的，即：将access_token埋入到cookie中，如果在APP中，是没有浏览器cookie参与的，因此在APP中可以采用JWT方案。其实JWT不仅可以解决APP与服务端的会话保持，在Web上也可以替代传统的Session方案。

四、子系统与SSO服务器

如下图所示，当用户张三在子系统A上进行过一次登陆认证后，在张三的浏览器中会产生两个域的cookie，一个是记录sso的会话(在cookie中有一个key=value的键值对)，另一个是记录子系统的会话(key=value,其中value就是子系统A的access_token)，其中前者称为全局会话或主会话，后者为局部会话或子会话；当张三再次打开浏览器访问其他子系统如B时，全局会话的cookie仍然有效并由子系统B重定向提交到SSO而子系统A的局部会话则由cookie跨域限制而无法提交上来，此时，SSO会校验全局会话的有效性而无需再次输入用户名和密码，SSO会产生一个供子系统B的access_token。
即：
1.子系统A和B共享与SSO的全局会话(只需要用户一次输入用户名密码进行认证)，各子系统与SSO之间分别有一个局部会话(即：access_token)。
2.张三通过子系统A登陆一次后，会在张三电脑浏览器的cookie中埋入两个域名下的key=value值，一个是全局会话SSO服务器的，另一个是子系统A的局部会话。

五、Oauth2.0的实现

1.官网Apache Oltu
2.与shiro的集成
3.HTTP验证大法(Basic Auth,Session, JWT, Oauth, Openid)

六、OpenID Connect

OpenID也是一种替代用户名密码的一种认证方式，如下所示是stackoverflow官网的登陆界面：



1.官网
2.实现
3.用通俗的例子解释OAuth和OpenID的区别

七、JS跨域

1.跨域的那些事儿
2.CORS是跨源资源分享（Cross-Origin Resource Sharing）的缩写。它是W3C标准，是跨源AJAX请求的根本解决方法。相比JSONP只能发GET请求，CORS允许任何类型的请求。详见：浏览器同源政策及其规避方法
3.跨域资源共享 CORS 详解
4.SSO中JS跨域重定向
5.基于 Cookie 的 SSO 中间件 kisso
6.nginx反向代理解决跨域 (个人认为最佳方案)

八、开源的账号与权限系统

1.用Python建设企业认证和权限控制平台 源码