目录：
* 名词定义
* OAuth的思路
* 运行流程
* 客户端的四种授权模式一、名词定义
（1） Third-party application：第三方应用程序，本文中又称”客户端”（client）。
（2）Resource Owner：资源所有者，本文中又称”用户”（user）。
（3）User Agent：用户代理，指浏览器、APP等。
（4）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（5）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
二、OAuth的思路
OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。
"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
三、运行流程
OAuth 2.0 的运行流程如下图，摘自RFC 6749。
（A）授权请求。用户打开客户端终端（web or APP）以后，客户端要求用户给予授权。这个授权请求可以直接提交给资源所有者。（如图所示），或最好是间接通过授权层作为中介进行授权。
（B）用户授权。客户端收到了一个来自用户的授权凭证。这个凭证，可以通过四种方式来获取，至于哪四种，下面有介绍。
（C）请求认证服务器授权。客户端使用上面用户授权得到的凭证向认证服务器请求一个拥有特定访问权限的访问令牌（access token），注意，access token 是和权限绑定的。
（D）发放令牌。认证服务器向客户端发放客户端在上一步请求的令牌。
（E）请求资源。客户端使用访问令牌向资源服务器请求用户的受保护的资源。
（F）返回资源。资源服务器验证访问令牌是否有效，有效则返回请求的资源。如何判断是否有效呢，当然是调用认证服务器的准备好的服务了。
上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。
四、客户端的四种授权模式
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0 定义了四种授权模式。
* 授权码模式（authorization code）
* 简化模式（implicit）
* 密码模式（resource owner password credentials）
* 客户端模式（client credentials）
1. 授权码模式
它的特点就是通过客户端的后台服务器，与”服务提供商”的认证服务器进行互动。授权码授权方式用于同时获取 accessToken 和 refreshToken，并对信任的客户端进行了优化。由于这是一个基于重定向的流程，client 必须能与 resource owner 的 user-agent（通常是浏览器）进行交互并且能够接收到 authorization server 通过重定向传入的请求。
（A）客户端将用户浏览器引导向认证端。客户端包含了客户端标识 client_id，请求授权范围 scope，本地状态state，回调地址 redirect_uri，一旦被授权（或被拒绝），认证服务器将会把回调地址返回给浏览器。
（B）用户操作授权，比如用户进行选择资源范围，输入密码点确定发送请求，决定是否给客户端授权。
（C）认证服务器校验用户真实性，假设用户给予授权，认证服务器将用户导向客户端事先指定的回调地址 redirect_uri，回调地址后面同时附上一个授权码 code 和之前设置的 state （这里的state，其实就是客户端预留的，用以当授权成功后，执行某些事件等，比如可以放一个js的方法名）。
（D）客户端使用上一步返回的授权码 code 附上之前用来获取授权码的回调地址 redirect_uri 向认证服务器请求一个访问令牌 （access token）。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，和在（C）步骤中的两个参数比对确认无误后，向客户端发送访问令牌（access token）和可选的刷新令牌（refresh token）。
在这个流程里面，有几个关键的参数，client_id，redirect_uri，code，access token，refresh token，下面简单解释一下。
client_id：客户端id。这个是认证端预先分配给客户端的。比如说，你要使用QQ登录新浪，那么新浪肯定是需要在QQ的认证中心备案的，然后 QQ 给新浪一个client_id，可能还有个secret，然后在约定一个回调地址 redirect_uri。然后新浪才能调用 QQ 的授权页面展示给用户看，让用户授权。
redirect_uri：回调地址。当你在QQ页面上授权完了，就会跳转到这个URI，就是授权成功后执行一些什么操作。如果没有这玩意的话，当你授权完了，然后呢，新浪也不知道接下来应该干嘛。
code：为什么要使用code呢？因为安全，这样，user agent 端只会出现code，正常情况下不会存在access token 和 refresh token，access token 和 refresh token只会在客户端即第三方的服务端和资源所在的服务器端流通。往往，客户端（user agent）被认为是不安全的，所以要尽量把重要的信息存在服务器端，以防止被篡改使用。
access token：即访问令牌。访问令牌用来访问资源信息，它本身就是权限，用户不可见。访问令牌的出现，可以让用户自主设定一个权限范围，也有了随时取消第三方权限的方式。它还有时效性，通常在返回该令牌的时候，也会随之返回一个有效时间，几十分钟到几十天不等，看认证服务器端的设置。OAuth 1.0 的时候，accessToken 是没有时间限制的，就是永久有效，这样的话，那第三方就能一直使用该令牌获取用户的资源，那如果用户好几个月都没有登录认证服务器设置，或者是忘记了，那么第三方就能永远可以访问，不太好，所以，在OAuth 2.0 的时候，增加了 refresh token。
refresh token：用途，看字面意思就知道，刷新令牌，当 access token 过期之后刷新出新的 access token。那就与上面的说法又矛盾了，这样一来的话，那不就是说可以一直使用 refresh token 来刷新出有效的 access token，这不就是变相的可以永久访问吗？确实，这是一个问题，所以，一般， refresh token 也是有时效性的，有过期时间，甚至，好多公司直接去掉了 refresh token ，仅仅返回有一定时间限制的 access token。那 refresh token 的存在意义又在哪里呢，应该是：有了它，可以改变 access token 的属性而不用再次经历授权。比如更改 accessToken 的权限的时候，只要使用 refresh token来刷新一个新的就好了，而不用再输入密码什么的。
2. 简化模式
简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
（A）客户端将用户导向认证服务器。
（B）用户决定是否给于客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
（F）浏览器执行上一步获得的脚本，提取出令牌。
（G）浏览器将令牌发给客户端。3.密码模式
密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。
在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
（C）认证服务器确认无误后，向客户端提供访问令牌。4.客户端模式
客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
（B）认证服务器确认无误后，向客户端提供访问令牌。
来源：oschina
链接：https://my.oschina.net/u/4129069/blog/3121741