OAuth 開放受權 Open Authorization

http://oauth.net/

 

http://tools.ietf.org/html/rfc6749

 

http://reg.163.com/help/help_oauth2.html

網易通行證OAuth2.0認證文檔

認證流程

OAuth2.0認證分爲3個步驟:

1)用戶受權並獲取code

2)使用code換取access_token

3)使用access_token獲取用戶信息

用戶受權並獲取code

URL：

http://reg.163.com/open/oauth2/authorize.do

HTTP請求方式:

GET

請求參數：

參數	意義
client_id	分配給第三方的key
redirect_uri	受權流程結束後跳轉的URL。redirect_uri所在的域名必須與申請OAuth認證郵件中網站域名一致
response_type	此值固定爲"code"
state（可選）	用於保證請求和回調用戶狀態統一，建議商家在state值中加入用戶狀態或使用session存儲state值。這個參數可用於防止跨站請求僞造（CSRF）攻擊

返回值：

參數	意義
code	獲取的Code
state	若是請求中傳了state參數，會回傳該參數用於校驗

返回示例：

http://YOUR_CALBACK_URL?code=A_CODE_GENERATED_BY_SERVER

錯誤時返回值：

參數	意義
error	錯誤類型
error_description	錯誤描述

錯誤時返回示例：

http://YOUR_CALBACK_URL?error=invalid_client&error_description=client+identifier+is+invalid

使用code換取access_token

URL：

http://reg.163.com/open/oauth2/token.do

HTTP請求方式:

POST

請求參數：

                

參數	意義
client_id	分配給第三方的key
client_secret	分配給第三方的secret
grant_type	此值固定爲"authorization_code"
code	第一步返回的code值
redirect_uri	必須與第一步所傳redirect_uri參數一致

返回值：

參數	意義
access_token	獲取的Access Token
expires_in	Access Token過時時間

返回示例：

{"expires_in":5184000,"access_token":"dab93a1e30960af28e6a975faeaf7c25"}

使用Access Token獲取用戶信息

URL：

https://reg.163.com/open/oauth2/getUserInfo.do

HTTP請求方式:

GET

請求參數：

                

參數	意義
access_token	第二步得到的access_token

返回值：

                

參數	意義
userId	用戶數字Id(長度不會超過15位)
username	用戶帳戶名稱(若是用戶在登陸的時候不選擇共享帳戶名稱，則只返回userId，因此請以userId做爲用戶的惟一標識)

返回示例：

{"username":"urstest_mreg","userId":"820014421"}（若是用戶在登陸的時候不選擇共享帳戶名稱，則返回：{"userId":"820014421"}）

申請OAuth認證

申請OAuth認證須要發送郵件到passport@service.netease.com, 郵件規範以下：

a. 申請郵件主題統一爲「申請OAuth認證」;

b. 郵件內容必須按照以下模板：

    1)網站名稱:__________________

    2)網站域名:__________________

    3)網站經營單位:__________________

    4)網站描述(不要超過85個字符):__________________

    5)網站的80*80px在線鏈接logo的url:__________________

    6)負責人手機號以及郵箱:__________________

    7)申請人贊成(郵件內容必須包含下面這段話)：

        網易公司有徹底權利根據申請人提交的信息審覈經過、不經過，或隨時終止給予申請人的受權和服務，且不對有關服務的穩定性、可持續性作任何明示或暗示的保證。

        申請人保證申請網站及其相關接口、通道的合法性、安全性、穩定性，不然給網易公司形成的損失應予以賠償；申請人完成申請、獲准經過後，應根據網易公司提供的信息數據進行開發，不得擅自變動用戶登陸網易通行證的頁面，不得以任何方式截取、蒐集、保存網易通行證用戶的任何用戶數據；申請人自行完成登陸結果信息的數據項校驗並獨立承擔後果。

        網易公司擁有網易通行證服務相關的一切權利，包括但不限於：網易通行證用戶登陸數據以及其它用戶數據、文字、軟件、聲音、圖片、錄像、圖表、廣告、電子郵件，等的所有內容。

c. 請嚴格按照以上規範，不然不予受理，審覈經過後，咱們會爲您分配相應的Consumer key和secret

 

 

 

 

http://article.yeeyan.org/view/50978/307535

OAuth 2.0：通往地獄之路

譯者： HorseLuke 原做者：Eran Hammer

發表時間：2012-08-05瀏覽量：8295評論數：2挑錯數：0

近日OAuth 2.0協議領導者之一Eran Hammer從OAuth工做組退出。他在博客中詳細闡述了OAuth 2.0並無達到兩個最重要的目標-安全和互操做性，認爲問題核心在於web和企業兩個世界之間存在不可調和的衝突，同時直言將OAuth帶入IETF是個巨大的錯誤

人們常說，通往地獄之路，常由善意鋪就[2][3]。好吧，我說的就是Oauth 2.0。

上個月我作出了一個痛苦的決定，完全和Oauth 2.0標準斷絕關係。我辭去首席做者和校正者，從規範中刪掉本身的名字，而後離開了工做組。從一份嘔心瀝血3年之久的文檔和超過24份的草稿中去掉本身的名字是多麼的不容易；而決定離開一個我領導5年之久爲之努力的領域則是多麼的痛心。

我作出這個極端決定，並非單一問題或者事件能夠解釋的。這是一次由數千次刀割所引起的死亡。隨着工做接近尾聲，我愈來愈深思究竟咱們在幹什麼。到了最後，我得出一個結論，Oauth 2.0是個爛協議，爛得和WS-*有得一拼，爛得我不想再和它產生任何關聯。這是我事業生涯中最大的一次職業挫敗。

不管是郵件列表、會議討論、特別設計委員會仍是祕密渠道，無數次艱難的爭論和妥協，最終產出的規範卻在兩個最重要目標上雙缺失——安全性和互操做性。實際上，有一份折中方案將它從「協議」從新命名爲「框架」，而另外一份則添加了一個免責聲明，警告這份規範並不能闡述互操做性的實現。

和Oauth 1.0相比，Oauth 2.0規範更復雜，缺少互操做性，實用性打折扣，更加不完整，最重要的是，更加不安全。

說得更明確些，Oauth 2.0若是在一個對互聯網安全有深刻了解開發者手上，實現結果大抵是安全的。然而，就這兩年經歷的狀況來看，Oauth 2.0在大部分開發者手中明顯出現了不安全的實現結果。

咱們怎麼到達這裏的？

這個問題的核心在於，互聯網（web）和企業（enterprise）這兩個世界之間有着強烈且難以彌合的衝突。IETF的OAuth工做組始於強烈的互聯網驅動氣勢。然而一年以後隨着工做一拖再拖，互聯網工做者已從最初的1.0社區一個個離去，結果工做組剩下的大部分都是企業人員…...而後還有我。

互聯網社區一直在尋找與1.0很是類似的協議，而且在某些缺少的方面進行小改善：簡化簽名，增長輕量級識別層，標記native application，增長更多流程以適應新的client類型，還有加強安全性。而企業社區則在尋找一種能夠最小化改動已有系統的框架，對某些人來說，還試圖尋求一種經過定製獲利的新來源。舉個例子理解這種分歧之深——在早期會議中，互聯網工做者想實現一種在瀏覽器內client的流程優化，而企業人員則想實現基於安全斷言標記語言（SAML）的流程。

由上述衝突產生的規範成爲了一種基於委員會設計、且更可能是爲了服務企業方的東拼西湊妥協物。更確切來講，它並不是用於知足企業全部直接的需求，它給予的是幾乎無限制的可擴展性。正是這種可擴展性和必需要求的靈活性，把這些協議給毀了。如今幾乎啥東西都不用費什麼努力，就能夠宣稱達到「Oauth 2.0兼容」標準了。

 

深刻了解[4]

要明白OAuth 2.0的問題，你須要瞭解它相比OAuth 1.0在覈心架構上有哪些變化:

無綁定token（Unbounded tokens） - 在1.0中，client若要訪問受保護資源（protected resource），則必須提供兩組憑據：token憑據（the token credentials，即Access Token和Access Token Secret）和client憑據（the client credentials，即常說的應用APP KEY和APP SECRET）。在2.0中，client憑據已經再也不被使用了，意味着token已經再也不綁定於任何一個特定的client類型或者實例。這樣的結果，既削弱了access token做爲一種認證（authentication）手段的做用，同時也增長了出現安全問題的可能性。[5]

無記名token（Bearer tokens[8]） - 2.0在協議層去掉全部簽名和加密要求，而僅僅依賴於傳輸層的TLS[6]。這意味着2.0的token在本質上處於更低安全係數的狀況。任何想提升token安全性的行爲必然要求額外的規範，而從目前提案展現的狀況來看，工做組僅僅着眼於企業應用範疇。

token失效（Expiring tokens） - 2.0的token存在過時時效，而且必須在過時時進行刷新。這對從1.0過來的client開發者而言是最大的改變，如今他們須要自行實現token狀態管理。之因此有token過時一說，是由於要適應自編碼token的實現——一種在服務器端無需進行數據庫查找便可進行認證的加密token。正由於這種自編碼token的存在，他們不可能被回收，只能強制爲短時效存在，以此減小遭受危險時帶來的損失。不管怎樣從（server端）去掉簽名所帶來的好處，都要在（client端）實現token狀態管理面前輸了兩回。

准許類型（Grant types[7]） - 在2.0中，受權准許（authorization grants）被用於交換獲取access token。准許是一種抽象概念，表明最終用戶已贊成受權。它能夠是用戶在訪問許可受權頁中點擊「Approve（贊成）」後獲取的一個code，也能夠是用戶實際的用戶名和密碼。之因此有這個概念，是爲了實現多重認證流程。1.0着眼於用1個認證流程適應於多種client類型，而2.0則是明顯爲不一樣的client類型增長多個特殊化認證流程。

猶豫不決的決策

以上的那些改變，若在一個良好定義的協議上實施是可控管理的。然而因爲工做組的組成性質，致使了問題（issue）要不陷在細節糾纏不清，要不就只能保持開放等待全部執行成員共同決定。如下僅是工做組沒法達成共識的一小部分例子：

- 不強制要求token類型

- 不能對協定基於HMAC算法token類型目標統一意見

- 不要求實施token過時

- 沒有關於token字段值長度的指導，其餘值相似

- 沒有嚴格要求註冊登記流程

- 弱定義client類型

- 缺少明晰的client安全屬性

- 不強制要求准許類型

- 沒有一個關於准許類型的適宜性或者適用性指導

- 沒有一個實用的native application支持（卻是有許多空口說白話）

- 沒有強制要求client認證機制

- 沒有限制可擴展性

另外一方面，OAuth 2.0爲可擴展性定義4個新的登記值，以及經過URI增長額外擴展點，結果引起了一堆關於擴展性的提案。然而真正的問題在於，工做組仍是不能爲協議定義真正的安全屬性。這很清晰地表如今安全考慮環節上，大多處於撲朔迷離的狀況。這致使安全專家幾乎沒有有效的聚焦點可供分析。實際上，工做組推出過70多頁用於描述2.0威脅模型的文檔，它試圖提供更多額外信息，但仍受困於一個相同的根本問題：沒有一個實質的協議可供分析。

現實

在現實世界，Facebook仍在運行着一年半前的草案12，並且也徹底沒有理由要他們升級現有的實現形式。畢竟，一個升級過的、用於實現Facebook對接的2.0 client也不太可能複用於其它Oauth服務提供方，反之亦然。Oauth 2.0一點也沒有提供代碼複用的潛力。

Oauth 2.0提供的是一個關於受權協議的藍圖（a blueprint for an authorization protocol）。正如上述定義所說，（獨立使用）它基本上毫無用武之地，必需要遷併入一個具體的工做解決方案中——而這正是企業化的方式，WS-*的套路。2.0提供了一個全新的領域，用來推銷諮詢服務和整合方案。

然而互聯網並不須要又一套安全框架。它須要的是一個簡單、良好定義、和恰如其分合適的協議，以此提升安全性和加強互操做性。（能夠說，）OAuth 2.0在尋求任何有意義的協議替代實現上失敗了。

升級，仍是停留

在最近幾個月，許多人都問我，他們是否應該升級到Oauth 2.0，又或者應該推薦哪一個協議版本給他們實現。個人答案是不能一律而論。

若是你如今用1.0用得很成功，忽略掉2.0吧。它並無比1.0體現出更好的價值。（我猜想，用大家服務的client開發者如今已經很熟悉1.0的簽名機制了。）

若是你在這個領域是個新來者，並且認爲本身是個安全專家，務必要在仔細當心地審查Oauth 2.0的各類特性後再使用。若是你不是專家，要不就使用Oauth 1.0，要不就複製一個你信得過的Oauth 2.0服務方實現形式，來把事情作對（Facebook的API文檔是一個很好的着手地方）。2.0對於大規模擴展（實施）相對較好，可是若是要運行大規模改造，你極可能還須要一些安全專家現場估算各類狀況和解決方案。

如今該咋辦？

我如今但願有人接手2.0，而後創做10頁左右、拋棄企業用途並更適用於絕大部分互聯網服務提供方的文檔。版本2.1應該更接近於版本1.5。可是在IETF，這根本不可能發生。在那個社區氛圍中，全都是企業級用例。若是你看看他們的其餘努力（好比OpenID Connect，原本超級簡單的提案最終變成了一大打複雜的規範）就會知道，他們沒能力讓事情簡化。

我認爲OAuth牌子已經在衰退。這個框架還會存在一段時間，而且在當前缺少替代品的狀況下，它還會獲得更普遍的接納。然而咱們更樂於看到接下來的幾年裏，Oauth 2.0會爆發各類重大的安全故障，還有其緩慢但穩步的品牌貶值。這將成爲又一個你所厭惡卻陷於其中泥潭的協議。

與此同時，我但願衆多新興社區們提出一些骨子裏更接近1.0而非2.0的東西。Oauth 1.0是全部關於小型互聯網創業團隊尋找快速解決已明肯定義問題的用戶方案。老實點說，我都不知道Oauth 2.0究竟要解決什麼樣的用例。

寫在最後

對於一個曾經有前途的社區，結論倒是悲哀的。OAuth曾做爲小型、快速且有用的標準模範，在標準機構以外無需繁瑣過程和法律花銷中產生。

（然而如今，）咱們的標準制定過程已經破碎地沒法修復。這個結局直接來源於IETF的本性，還有監督這份工做時的某些特定性格。更直白地說，這並不是因爲某些壞人或者無能者致使的。偏偏相反，你們都很是有才華、聰明、和善可親等等。然而大多數人表態只爲自身企業領域服務，而剩下的咱們已在事實上沒法與之競爭。

將OAuth帶入IETF是個巨大的錯誤。另外一種替代方案WRAP也不會有更好的結局，但至少不用花費3年時間才得知這個下場。只要能堅持住，我儘量地留在裏面，去爲我自認爲最適合互聯網的模式而戰。但是就本身而言，我並無從所作的決策中獲得什麼。到了最後，一個反對派的聲音只能將事情延緩，但不能改變什麼。

我失敗了。

咱們都失敗了。

插圖翻譯：

- 噢，老天他們扼殺了Oauth。

- 你妹的！

一些更多思考…...

 

 

譯註：

==========================

[1] 部分詞彙並無翻譯，緣由是開發者和架構師在交流OAuth協議時，基本傾向於直接使用英文詞彙單詞，而此文翻譯也主要面向他們，故保留原意。如下給出這些詞彙的意思：

token：訪問令牌。可簡單理解爲打開家門的鑰匙、門禁卡等。

server：OAuth服務器，服務器提供方。

client：客戶端，和提交到IETF以前的「消費方」（Consumer）等義。可簡單理解爲直接向OAuth服務器發起請求的應用、客戶端、甚至是瀏覽器等。

native application：原生應用。通常爲手機APP和桌面程序。

[2]本文開始部分的翻譯參照了開源中國的文章，在此致謝：http://www.oschina.net/news/31399/oauth20-road-to-hell

[3] 此話至關於「好心辦壞事」。來源不可考：http://zhidao.baidu.com/question/32462302.html

[4] 關於「深刻了解」部分，若是不瞭解OAuth協議的開發者，可參考如下給出新浪微博開放平臺的調用用戶信息API接口的請求例子（HTTP HEADER部分），再對照原文閱讀：

【HTTP, Sina weibo OAuth 1.0a】

GET /users/show/123456.json?oauth_consumer_key=【應用APP KEY】&oauth_nonce=【OAuth隨機值】&oauth_signature=【查詢參數+應用APP SECRET+Access Token Secret三者共同進行簽名後的值】&oauth_signature_method=HMAC-SHA1&oauth_timestamp=【請求時間】&oauth_token=【Access Token】&oauth_version=1.0a HTTP/1.1

Host: api.t.sina.com.cn

 

【HTTPS, Sina weibo OAuth 2.0】

Host: api.weibo.com

GET /2/users/show.json?uid=123456 HTTP/1.1

Authorization: OAuth2 【Access Token】

 

[5] 可參照微軟研究組發給IETF的信件：http://www.ietf.org/mail-archive/web/oauth/current/msg09270.html

[6] 常說的HTTPS

[7] 此處grant爲名詞

[8] 參見：http://www.infoq.com/cn/news/2010/09/oauth2-bad-for-web

 

==============

翻譯存疑：

[1] addressing native applications：因爲本人開發背景是web開發，故此處暫不能理解。暫時翻譯爲「標記native application」。

[2] 「But most of them show up to serve their corporate overlords」。這句咋理解？

[3] 「The web community was looking for a protocol very much in-line with 1.0, with small improvement in areas that proved lacking」。area指的是1.0這個協議呢，仍是說在尋找中的協議呢？從工做經驗看，彷佛是後者？

[4] 「produced outside standards bodies without all the process and legal overhead」 這話好想意譯爲「在標準機構以外野蠻生長」的-_-||