OAuth 2.0规范于2012年发布，很多大型互联网公司（比如：微信、微博、支付宝）对外提供的SDK中，授权部分基本上都是按这个规范来实现的。
OAuth 2.0提供了4种基本的标准授权流程，最为复杂的是Code（授权码）这种类型，流程图如下：(摘自RFC6749官方文档)
上图中有几个术语解释一下：
Resource: 受保护的资源，比如：用户abc在微信上的用户资料(头像，朋友圈之类)
Resource Owner:资源所有人，即：上面讲的用户abc
Client:指第三方应用，比如：微信
Authorization Server:授权服务器，可以理解成微信对外开放的SDK授权API
User-Agent: 用户代理，在一般的互联网应用中，这个通常就是指浏览器
其实这张图中，还隐藏了一个身份：Resource Server资源服务器，即真正提供资源访问接口的服务
整个流程如下：
A: 浏览器(User-Agent)请求第三方应用比如微信(Client)上的资源，这时候还没有access_token，所以微信会请求重定向到认证服务器（Authorization Server）
B: 认证服务器这时会呈现出一个授权界面(即：我们经常在手机遇到的微信授权认证界面，告诉用户XXX应用正在请求您在微信上的资料，然后下面有一个"同意授权"的按钮)
C: 用户同意授权后，认证服务器会返回浏览器一个code（本文称为授权码），通俗的理解，相当于浏览器这时候取了一个号(就象我们去银行办业务，大堂经理先给你一个排队号，这个号码并非敏感信息，被其它人知道了， 一般问题也不大)，浏览器拿着这个号再去请求微信上的资源
D：再次被重定向到认证服务器，用code来换真正的访问令牌(access_token) (有点类似于银行排到你的号了，你拿这个号去X号柜台真正办理业务，这时人家会让你出示身份证，卡号等敏感信息，只不过在oAuth 2中，这些敏感信息是动态生成，有时效限制的)，最终浏览器拿到了access_token
E: 有了access_token，浏览器访问微信上受保护的资源时，资源服务器校验access_token的合法性后，返回用户想要的资源。
注：上面提到的银行取号办理业务，这个示例可能有点牵强，大家主要记住[授权->拿Code->用Code换Access_Token->带着Access_Token访问资源]这一套流程。
下面这张图可能更容易理解一些：
除了授权码这种常用流程外，还有一种用户名、密码的流程也被广泛使用，序列图如下：
password模式与code模式最大的不同，在于没有code换access_token这一步。另外：由于access_token的有效期比较短，为了避免频繁按上述流程重新获取新access_token，oAuth还有一个refresh_token的概念，通常refresh_token过期时间比较长(比如：一周甚至更长)，当发现access_token快过期时，可以主动用refresh_token去获取一个新的access_token，序列图如下：
流程搞清楚了，最后谈谈实现，spring-security有一个oAuth2的"插件"，可以直接在spring-security的基础上支持oAuth2.0，项目地址：https://github.com/spring-projects/spring-security-oauth，项目的/samples/oauth2/下有二个示例，对应oAuth server与oAuth client端，有兴趣的可以研究下。
此外，oschina还有二个国人提供的优秀示例，我已经搬到github上了，地址：
https://github.com/yjmyzz/spring-oauth-server
https://github.com/yjmyzz/spring-oauth-client
不过关于spring-security-oauth2有几点要注意一下：
a)默认access_token的时间非常长，大约是12小时，建议调小
b)在access_token未过期时，多次请求将返回同一个access_token
c)在code模式下，client_secrect在第二步code换access_token时，才需要，第一步申请code不需要
参考文章：
