OAuth是一个关于受权（authorization）的开放网络标准，在全世界获得普遍应用，目前的版本是2.0版。git
本文对OAuth 2.0的设计思路和运行流程，作一个简明通俗的解释，主要参考材料为RFC 6749。github
1、应用场景
为了理解OAuth的适用场合，让我举一个假设的例子。web
有一个"云冲印"的网站，能够将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取本身储存在Google上的照片。spring
问题是只有获得用户的受权，Google才会赞成"云冲印"读取这些照片。那么，"云冲印"怎样得到用户的受权呢？数据库
传统方法是，用户将本身的Google用户名和密码，告诉"云冲印"，后者就能够读取用户的照片了。这样的作法有如下几个严重的缺点。json
（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。api
（2）Google不得不部署密码登陆，而咱们知道，单纯的密码登陆并不安全。
（3）"云冲印"拥有了获取用户储存在Google全部资料的权力，用户无法限制"云冲印"得到受权的范围和有效期。
（4）用户只有修改密码，才能收回赋予"云冲印"的权力。可是这样作，会使得其余全部得到用户受权的第三方应用程序所有失效。
（5）只要有一个第三方应用程序被破解，就会致使用户密码泄漏，以及全部被密码保护的数据泄漏。
OAuth就是为了解决上面这些问题而诞生的。
2、名词定义
在详细讲解OAuth 2.0以前，须要了解几个专用名词。它们对读懂后面的讲解，尤为是几张图，相当重要。
（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。
（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。
（3）Resource Owner：资源全部者，本文中又称"用户"（user）。
（4）User Agent：用户代理，本文中就是指浏览器。
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，能够是同一台服务器，也能够是不一样的服务器。
知道了上面这些名词，就不难理解，OAuth的做用就是让"客户端"安全可控地获取"用户"的受权，与"服务商提供商"进行互动。
3、OAuth的思路
OAuth在"客户端"与"服务提供商"之间，设置了一个受权层（authorization layer）。"客户端"不能直接登陆"服务提供商"，只能登陆受权层，以此将用户与客户端区分开来。"客户端"登陆受权层所用的令牌（token），与用户的密码不一样。用户能够在登陆的时候，指定受权层令牌的权限范围和有效期。
"客户端"登陆受权层之后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
4、运行流程
OAuth 2.0的运行流程以下图，摘自RFC 6749。
（A）用户打开客户端之后，客户端要求用户给予受权。
（B）用户赞成给予客户端受权。
（C）客户端使用上一步得到的受权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证之后，确认无误，赞成发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，赞成向客户端开放资源。
不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端受权。有了这个受权之后，客户端就能够获取令牌，进而凭令牌获取资源。
下面一一讲解客户端获取受权的四种模式。
5、客户端的受权模式
客户端必须获得用户的受权（authorization grant），才能得到令牌（access token）。OAuth 2.0定义了四种受权方式。
- 受权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
6、受权码模式
受权码模式（authorization code）是功能最完整、流程最严密的受权模式。它的特色就是经过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
它的步骤以下：
（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端受权。
（C）假设用户给予受权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个受权码。
（D）客户端收到受权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了受权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
下面是上面这些步骤所须要的参数。
A步骤中，客户端申请认证的URI，包含如下参数：
- response_type：表示受权类型，必选项，此处的值固定为"code"
- client_id：表示客户端的ID，必选项
- redirect_uri：表示重定向URI，可选项
- scope：表示申请的权限范围，可选项
- state：表示客户端的当前状态，能够指定任意值，认证服务器会原封不动地返回这个值。
下面是一个例子。
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
C步骤中，服务器回应客户端的URI，包含如下参数：
- code：表示受权码，必选项。该码的有效期应该很短，一般设为10分钟，客户端只能使用该码一次，不然会被受权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
- state：若是客户端的请求中包含这个参数，认证服务器的回应也必须如出一辙包含这个参数。
下面是一个例子。
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含如下参数：
- grant_type：表示使用的受权模式，必选项，此处的值固定为"authorization_code"。
- code：表示上一步得到的受权码，必选项。
- redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
- client_id：表示客户端ID，必选项。
下面是一个例子。
POST /token HTTP/1.1
Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
E步骤中，认证服务器发送的HTTP回复，包含如下参数：
- access_token：表示访问令牌，必选项。
- token_type：表示令牌类型，该值大小写不敏感，必选项，能够是bearer类型或mac类型。
- expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
- refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
- scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。
下面是一个例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
从上面代码能够看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。
7、简化模式
简化模式（implicit grant type）不经过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"受权码"这个步骤，所以得名。全部步骤在浏览器中完成，令牌对访问者是可见的，且客户端不须要认证。
它的步骤以下：
（A）客户端将用户导向认证服务器。
（B）用户决定是否给于客户端受权。
（C）假设用户给予受权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码能够获取Hash值中的令牌。
（F）浏览器执行上一步得到的脚本，提取出令牌。
（G）浏览器将令牌发给客户端。
下面是上面这些步骤所须要的参数。
A步骤中，客户端发出的HTTP请求，包含如下参数：
- response_type：表示受权类型，此处的值固定为"token"，必选项。
- client_id：表示客户端的ID，必选项。
- redirect_uri：表示重定向的URI，可选项。
- scope：表示权限范围，可选项。
- state：表示客户端的当前状态，能够指定任意值，认证服务器会原封不动地返回这个值。
下面是一个例子。
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
C步骤中，认证服务器回应客户端的URI，包含如下参数：
- access_token：表示访问令牌，必选项。
- token_type：表示令牌类型，该值大小写不敏感，必选项。
- expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
- scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。
- state：若是客户端的请求中包含这个参数，认证服务器的回应也必须如出一辙包含这个参数。
下面是一个例子。
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
在上面的例子中，认证服务器用HTTP头信息的Location栏，指定浏览器重定向的网址。注意，在这个网址的Hash部分包含了令牌。
根据上面的D步骤，下一步浏览器会访问Location指定的网址，可是Hash部分不会发送。接下来的E步骤，服务提供商的资源服务器发送过来的代码，会提取出Hash中的令牌。
8、密码模式
密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供本身的用户名和密码。客户端使用这些信息，向"服务商提供商"索要受权。
在这种模式中，用户必须把本身的密码给客户端，可是客户端不得储存密码。这一般用在用户对客户端高度信任的状况下，好比客户端是操做系统的一部分，或者由一个著名公司出品。而认证服务器只有在其余受权模式没法执行的状况下，才能考虑使用这种模式。
它的步骤以下：
（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
（C）认证服务器确认无误后，向客户端提供访问令牌。
B步骤中，客户端发出的HTTP请求，包含如下参数：
- grant_type：表示受权类型，此处的值固定为"password"，必选项。
- username：表示用户名，必选项。
- password：表示用户的密码，必选项。
- scope：表示权限范围，可选项。
下面是一个例子。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
上面代码中，各个参数的含义参见《受权码模式》一节。
整个过程当中，客户端不得保存用户的密码。
9、客户端模式
客户端模式（Client Credentials Grant）指客户端以本身的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以本身的名义要求"服务提供商"提供服务，其实不存在受权问题。
它的步骤以下：
（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
（B）认证服务器确认无误后，向客户端提供访问令牌。
A步骤中，客户端发出的HTTP请求，包含如下参数：
- granttype：表示受权类型，此处的值固定为"clientcredentials"，必选项。
- scope：表示权限范围，可选项。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
认证服务器必须以某种方式，验证客户端身份。
B步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" }
上面代码中，各个参数的含义参见《受权码模式》一节。
10、更新令牌
若是用户访问的时候，客户端的"访问令牌"已通过期，则须要使用"更新令牌"申请一个新的访问令牌。
客户端发出更新令牌的HTTP请求，包含如下参数：
- granttype：表示使用的受权模式，此处的值固定为"refreshtoken"，必选项。
- refresh_token：表示早前收到的更新令牌，必选项。
- scope：表示申请的受权范围，不能够超出上一次申请的范围，若是省略该参数，则表示与上一次一致。
下面是一个例子。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
（完）
周梦康 说：
阮老师的文章都是精品，真正作到深刻浅出。
2014年5月12日 22:10 | # | 引用
hutusi 说：
留名，慢慢看~
2014年5月12日 22:58 | # | 引用
chility 说：
今天培训老师讲了这部分，刚好阮老师写了这篇文章介绍，加深理解。
2014年5月13日 00:31 | # | 引用
phi 说：
那什么，没看懂。能不能用位图。ASCII图看的很不习惯。谢谢
2014年5月13日 01:24 | # | 引用
WhatDoesTheFoxSay 说：
受权码模式这部分中的“E步骤中，客户端发送的HTTP回复，包含如下参数“这句话，是否应为”认证服务器发送的HTTP回复“？
2014年5月13日 05:00 | # | 引用
Charles 说：
本文关于state参数的解释，是语焉不详的。事实上，绝大多数的互联网中文文档对这个参数都语焉不详。我想，对于形成近期互联网上危害普遍的OAuth漏洞来讲，众多中文技术资料对这个参数解释不到位，对这个参数的实现没有给出清晰的指导，也是成因的一部分。原文是这么说的：RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.若是阮老师只是翻译为何“客户端状态”之类的话，还有什么“能够随便填”，这算不上一种到位的解释。首先，这个参数是“RECOMMENDED”，并不是什么无关紧要的东西，事实是不少厂商都实现成了无关紧要，其次，这个参数是“SHOULD”，为啥“SHOULD”呢，由于会引起“CSRF”。
2014年5月13日 07:41 | # | 引用
阮一峰 说：
谢谢指出，已经改过来了。
2014年5月13日 08:44 | # | 引用
Tonni 说：
阮兄的博客又更新了，前几天买的《黑客与画家》昨天到了，很不错的书。
2014年5月13日 09:05 | # | 引用
YG 说：
看了这么多OAuth的文章，阮老师的这篇是最好懂的，拜读了
2014年5月14日 08:19 | # | 引用
M16 说：
说白了oauth就是一个网络版的usbkey
2014年5月17日 13:50 | # | 引用
洋子 说：
支付宝连接已失效
2014年5月18日 22:56 | # | 引用
Nicole 说：
很是感谢老师的分享，收益了。。
2014年5月20日 09:13 | # | 引用
匆匆过客 说：
仔细一看，确实，若是state项不用动态数据的话会存在CSRF漏洞
2014年5月20日 09:39 | # | 引用
smilexu 说：
（E）客户端使用令牌，向资源服务器申请获取资源。
令牌就能够？整个过程都没有用户名和密码的得到，那资源服务器又是如何确认用户的？
2014年5月21日 12:01 | # | 引用
万文婷 说：
我是比较文学与世界文学的硕士生，但愿您能联系我，探讨一下卡尔维诺。
2014年5月21日 16:19 | # | 引用
niannian 说：
受权码模式中，D步骤，文中说client_id是必选项，可是随后的例子中没有这项
2014年5月23日 14:12 | # | 引用
spojus 说：
收款主页下线啦
2014年5月24日 23:01 | # | 引用
loddit 说：
同ls的niannian
另外 granttype authorizationcode 都没加 _ 下划线
2014年5月24日 23:20 | # | 引用
Ike 说：
話說，RFC本來就是純文字檔案，這樣的圖其實看了很親切。。。
2014年5月25日 16:14 | # | 引用
rhgb 说：
2014年6月 7日 16:47 | # | 引用
king 说：
若是客户端作一个假的验证受权页面，来套取用户，用户名和密码，是有可能的吧？
2014年6月12日 11:30 | # | 引用
jucelin 说：
我也有此疑问。weibo.com提供的都提示"请认准本页URL地址必须以 api.weibo.com 开头"，这提示基本上没用。
2014年6月16日 20:41 | # | 引用
mll 说：
协议中的 SHOULD，应该等同于 MUST 来对待。
2014年6月19日 17:25 | # | 引用
sjh 说：
工商银行的网银在开通时要求用户本身说一句话，每次使用网银付款时网站会向用户出示这句话以证实网站的合法性。这个感受要好些吧~
2014年7月18日 17:27 | # | 引用
lvqiuyi 说：
有两点不太明白
1.受权码受权里，为何要两次传递重定向url呢？有什么好处？
2.D步骤里，传递的参数有Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW，什么做用呢？
2014年8月 5日 11:24 | # | 引用
lvqiuyi 说：
懂了，Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW，应该是对于应用client的受权认证，这样就至关于有两层保护，一层是认证客户端，一层是认证用户，不过basic的加密方式，是否是不太安全呢？
2014年8月 5日 14:44 | # | 引用
suolaiwo 说：
请问一下，受权码code，其做用是什么？
2014年9月 8日 14:29 | # | 引用
guest 说：
本质的做用是避免Access Token经过URL返回，有篇视频讲这个比较详细《[开放平台]一步一步理解OAuth2协议-全网首发》
http://edu.51cto.com/index.php?do=course&m=addlession&course_id=2035
2014年9月16日 14:30 | # | 引用
zhiwen 说：
请问你这个是使用什么框架实现的OAuth的相关服务器端的？
2014年9月18日 13:55 | # | 引用
陈伟 说：
正在学习OAuth2，写得太好了！很是容易理解！
2014年10月21日 16:57 | # | 引用
hebidu 说：
我想知道 如何 生成access_token ，refresh_token 。
2014年10月22日 12:45 | # | 引用
James 说：
生成access_token ，refresh_token 很简单,取一惟一的随机信息再作BASE64编码便可,它自己不包含任何有效信息的;服务端把它和用户授权关联以校验其授权的有效性.
2014年10月29日 10:45 | # | 引用
惜今草 说：
请问，OAuth2.0客户端认证模式怎么限制客户端到认证服务器申请权限的范围(Scope)？
2014年11月12日 16:11 | # | 引用
yxwoods 说：
通俗易懂！感受如等到风来吹开京都雾霾，重见蓝天白云！
2014年11月13日 09:25 | # | 引用
jinlong 说：
引导用户到受权界面，用户会先登陆后受权，整个受权过程当中没有提到到底是为“谁”受权的啊？ 那token是怎么和userid进行映射的呢？
我开始理解的是，用户赞成受权后，会告诉受权服务器client_id等参数外还会有userid。
2014年11月21日 16:12 | # | 引用
HM 说：
阮老师为啥只发文而不答复上面技术性的探讨呢？
2014年12月 9日 12:47 | # | 引用
feiniu5566 说：
你要知道这个受权的目的是给第三方应用受权，让他有权利去获取用户放在服务器上的资源，因此你应该站在第三方应用的角度来看待这篇文章，你的目的就是获取用户
QQ空间里的图片，就这么理解吧，差不想为那个什么讯发广告
2014年12月 9日 16:31 | # | 引用
yuandghn 说：
确实是这样的，不少时候你们都忽略了这个state参数存在的意义。企鹅家的OAuth2.0文档里却是把这个参数说的很详细(非广告，实话实说)。
2015年1月25日 18:00 | # | 引用
smithfox 说：
密码模式的例子中Request Header 中的 Authorization 是怎么来的？
2015年1月28日 12:39 | # | 引用
xiaozi0lei 说：
文章写的不错，深刻浅出，正好在找Oauth 2.0相关的介绍文章，有帮助，多谢！
2015年3月 3日 15:49 | # | 引用
alleme 说：
确实,刚查了腾讯文档 "state 可选 client端的状态值。用于第三方应用防止CSRF攻击，成功受权后回调时会原样带回。"
2015年3月11日 11:05 | # | 引用
Shion 说：
拿到访问令牌（access token）后，是否是每次请求资源都必须附上访问令牌？OAuth2是否是只适合Http，基于OAuth2的都只能经过客户端轮询来获取最新状态而不能由服务端进行推送？
2015年4月10日 16:38 | # | 引用
test 说：
简化模式中：
C）假设用户给予受权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码能够获取Hash值中的令牌。
c处的hash有没有多余呢？谢谢
2015年4月14日 08:21 | # | 引用
许广辉 说：
每次看到你这儿，东西就看明白了，简单清晰
2015年4月16日 15:52 | # | 引用
shengzhao 说：
具体的参考实现: http://git.oschina.net/shengzhao/spring-oauth-server
整合Spring Security与Oauth2 的完整代码.
2015年4月20日 15:00 | # | 引用
song 说：
描述的很好，不错。多谢了！
2015年5月13日 17:46 | # | 引用
小正 说：
首先谢谢阮老师，学习了，我想问下token存在数据库仍是session里好呢
存数据库是否是存一个过时时间(或者之类的)，还有若是用户操做了，这个token就延长时间仍是固定死的(几个小时就几小时几天就几天)以后过时再用refresh取
2015年6月 3日 15:18 | # | 引用
小正 说：
我查了一些资料，基本捋顺了
2015年6月 4日 09:37 | # | 引用
杨鹏 说：
感谢分享！
2015年7月18日 09:49 | # | 引用
小超人 说：
受权码模式,为何不能经过一次请求获取访问令牌?为何非要加上一次受权码请求呢?如今受权码的做用是指定访问范围,那为何不能够把访问范围做为参数传给认证服务器经过一次请求获取访问令牌呢?
2015年7月20日 10:09 | # | 引用
小超人 说：
受权码模式比简化模式好在哪里呢?求路过大神指点
2015年7月20日 10:19 | # | 引用
小超人 说：
2015年7月20日 10:23 | # | 引用
卡萨布兰卡 说：
有一处clientcredentials，应该改成：client_credentials
2015年8月 3日 16:58 | # | 引用
newnius 说：
这个token能够是唯一的，也就是说，token惟一肯定一个用户，像@feiniu5566 说的，客户端能够经过令牌请求用户信息，包括userid，因此没有必要额外发送。
2015年8月13日 17:35 | # | 引用
williamwue 说：
写得十分清楚明白，多谢博主！
2015年8月19日 16:20 | # | 引用
helm 说：
阮老师，受权码模式中A步骤中的redirect_uri写的是可选项，D步骤说的是必选项，这里是否是有矛盾
2015年8月22日 12:15 | # | 引用
damon 说：
大学的时候接触淘宝API，也碰到：受权码模式， 可是知道看了这篇文章才系统的理解。。
谢了！
2015年9月15日 18:01 | # | 引用
xiaoC 说：
最近在搞第三方登入，虽然已经按文档弄好了，可是并不懂OAuth为什么物，看了楼主介绍总结，非常详细，多谢楼主
2015年9月20日 01:27 | # | 引用
我爱demo 说：
最近要弄这个， 虽然几天了仍是没什么进度，不过看了这篇文章感受很详细，虽然并不懂。
2015年10月 6日 16:35 | # | 引用
aehyok 说：
灰常好，学到了不少，谢谢大拿
2015年10月10日 15:22 | # | 引用
分崩离析 说：
令牌就能够表明用户，资源服务器只负责提供资源
2015年11月 4日 10:39 | # | 引用
陈柏成 说：
（C）假设用户给予受权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个受权码。
我不明白这个URI是用来跳转到认证服务器的url 仍是指向前面例子说的云冲印的图片 谢谢了^^
2015年11月16日 11:40 | # | 引用
h 说：
这个令牌是一个字符串，资源服务器如何鉴别这个字符串不是伪造的呢？须要资源服务器到认证服务器上去鉴别吗，仍是两边约定一种鉴别机制(好比鉴别RMB同样)
2015年12月16日 10:08 | # | 引用
h 说：
看了 RFC 文档
http://tools.ietf.org/html/rfc6749
明白了，仍是须要在 AS 和 RS 之间有个交互。
7. Accessing Protected Resources
The client accesses protected resources by presenting the access
token to the resource server. The resource server MUST validate the
access token and ensure that it has not expired and that its scope
covers the requested resource. The methods used by the resource
server to validate the access token (as well as any error responses)
are beyond the scope of this specification but generally involve an
interaction or coordination between the resource server and the
authorization server.
2015年12月16日 11:42 | # | 引用
h 说：
http://tools.ietf.org/html/rfc6749
Accessing Protected Resources
The client accesses protected resources by presenting the access
token to the resource server. The resource server MUST validate the
access token and ensure that it has not expired and that its scope
covers the requested resource. The methods used by the resource
server to validate the access token (as well as any error responses)
are beyond the scope of this specification but generally involve an
interaction or coordination between the resource server and the
authorization server.
少不了 RS 到 AS 之间交互认证 access_token，这个 Oauth 没有规定啊,能够随意发挥啊。
2015年12月16日 11:45 | # | 引用
兴杰 说：
看了好几回，今天终于明白第一种模式了，谢谢老师 ^^
2015年12月18日 19:00 | # | 引用
Ans 说：
不错，好文章！
2015年12月23日 11:01 | # | 引用
Laughing_Lz 说：
restful一头雾水，老师太深奥，仍是不懂，泪奔啊
2015年12月23日 17:56 | # | 引用
喵喵 说：
AS完成受权以后 把受权码和state附在重定向URI以后 再把浏览器重定向回这个地址 redirection URI是client提供的一个地址 作这一步是为了让Client可以得到受权码
2015年12月24日 10:25 | # | 引用
喵喵 说：
请教阮老师和路过大神：
我一直对implicit grant中的web-hosted client resource的做用感到疑惑
为何须要先向web-hosted client resource请求一个包含JS代码html 而后再用JS来读取access_token in Fragment(Hash)最后得到access_token 为何不直接在本地用JS代码来读取呢？ 我在stackoverflow上看到人说这是重定向的经常使用作法 并无涉及到安全性的考虑 可是为何要这样作呢？
2015年12月24日 10:36 | # | 引用
喵喵 说：
恩 先说为何implicit grant不须要Authorization code吧 首先由于Authorization code和client secret是不会暴露给用户的 这个是服务器与服务器之间通讯才须要的 因此implicit grant是经过user-agent（web browser）来与AS交互 你加上这两个东西以后 仍是会暴露给用户看到的 因此没有必要在简化模式中增长他的复杂性
如今回到你问的 为何受权码模式须要这个受权码 固然是为了安全性 首先在OAuth体系中access_token是做为访问获取资源的惟一凭据 若是在AS受权完成以后 直接经过重定向传回access_token 那么HTTP 302不是安全的 Attacker有可能会获取到access_token 可是若是只返回Authorization code 就算别人得到了也没什么卵用 由于Authorization code不能获取到资源 在client向AS请求access_token的过程当中 是经过HTTPS来保证安全的 并且得到access_token是须要client secret与Authorization code一块儿的 Attacker知道了Authorization code但并不知道client secret 一样也不能得到到access_token 因此client与AS是有责任保护好client secret的
得到了access_token以后 向RS发起请求 RS其实会与AS交互 来校验access_token 因此你想直接伪造一个access_token 那也是不ok的
2015年12月24日 11:03 | # | 引用
存在感为零的人 说：
很透彻
2015年12月24日 11:59 | # | 引用
喵喵 说：
忽然想到漏说了一块 关于为何不直接用HTTPS重定向回client
是由于不是全部client server都支持HTTPS~因此为了通用性 和安全性 才衍生出来这么一个Auth code
可是AS确定是实现HTTPS的 因此在client向AS提起request 是木有问题的~
2015年12月24日 14:54 | # | 引用
李先森 说：
不太明白 为何使用auth_code换取access_token的时候 还要传redirect_uri
2016年1月10日 13:39 | # | 引用
北言 说：
最近在学习oauth2,看了阮老师的文章,很透彻,明白了.
2016年2月17日 11:33 | # | 引用
见解 说：
写的很好，有参考价值
2016年2月22日 17:37 | # | 引用
雅爱 说：
您好，想谈论下，在更新资源令牌的时候为何要使用专门的更新令牌来更新资源令牌？为什么不直接用资源令牌来更新资源令牌？
2016年3月25日 08:51 | # | 引用
popwar 说：
有些解释不够详细，看看这个tutorial更容易理解http://tutorials.jenkov.com/oauth2/index.html
2016年4月 1日 13:40 | # | 引用
zsxkarl 说：
最近在了解oauth，多谢详细讲解！
2016年4月26日 21:11 | # | 引用