訪問oauth路徑要不要認證

① 新浪OAuth和Basic Auth兩種方式的區別

開放平台有兩種認證方式，一種是Basic Auth，一種是OAuth。
1、Basic Auth（HTTP Auth）
Basic Auth簡單點說明就是每次請求API時都提供用戶的username和password。
。這種方式優點和缺點都很明顯。
優點：
u 使用非常簡單，
u 開發和調試工作簡單，
u 沒有復雜的頁面跳轉邏輯和交互過程；
u 更利於發起方控制；
缺點：
u 安全性低，每次都需要傳遞用戶名和密碼，用戶名和密碼很大程度上存在被監聽盜取的可能；
u 同時應用本地還需要保存用戶名和密碼，在應用本身的安全性來說，也存在很大問題；
u 開放平台服務商出於自身安全性的考慮（第三方可以得到該服務商用戶的賬號密碼，對於服務商來說是一種安全隱患），未來也會限制此認證方式（Twitter就計劃在6月份停止Basic Auth的支持）
u 用戶如果更改了用戶名和密碼，還需要重新進行密碼校驗的過程。
2、OAuth
OAuth為用戶資源的授權提供了一個安全、開放的標准，將會是以後開發平台普遍遵守的，目前Twitter、Sina微博、豆瓣、Google等都提供對它的支持。它分為幾個交互過程：
1）應用用APP KEY和APP SECRET換取OAuth_token；
2）應用將用戶引導到服務商的頁面對該OAuth_token進行授權（可能需要輸入用戶名和密碼）；
3）服務商的頁面跳轉回應用，應用再根據參數去服務商獲得Access Token；
4）使用這個Access Token就可以訪問API了。
上述過程如下圖所示：
OAuth認證過程
OAuth的優點：
u 安全性高，用戶的賬戶和密碼只需要提供一次，而且是在服務商的頁面上提供，防止了Basic Auth反復傳輸密碼帶來的安全隱患；
u Access Token訪問許可權僅限於應用，被竊取不會影響用戶在該服務商的其他服務；
u Access Token即使被監聽丟失了隨時可以撤銷，不像密碼丟失可能就被別人篡改了；
u 用戶修改了密碼也不會影響該應用的正常使用。
OAuth和Basic Auth兩種方式的區別, OAuth是一種比較通用的，安全的認證方式，不需要用戶名密碼，只需要用戶授權；basic auth是一種基於用戶名密碼的認證，每次訪問都需帶上用戶的用戶名密碼。

② OAUTH，OPENID，SAML，CAS做統一認證與授權時有什麼區別

OpenID是Authentication
OAuth是Authorization

前者是網站對用戶進行認證，讓網站知道逗你是你所聲稱的URL的屬主地
後者其實並不包括認證，只不過逗只有認證成功的人才能進行授權地，結果類似於逗認證+授權地了。OAuth相當於：A網站給B網站一個令牌，然後告訴B網站說根據這個令牌你可以獲取到某用戶在A網站上允許你訪問的所有信息

如果A網站需要用B網站的用戶系統進行登錄（學名好像叫federated login），它可以

選擇OpenID認證，然後通過attribute exchange獲取用戶的昵稱或其他通過OpenID暴露出來的用戶屬性，或者
選擇OAuth認證，獲取到token後再用token獲取用戶昵稱或其他允許被訪問的信息

③ REST API 只給自己的APP提供介面，需要oauth認證嗎

1 就算有oauth也不能限定app吧.
oauth的本質上是提供第三方認證服務的.所以如果本來不需要登錄的應用,應該就不需要使用oauth.

2如何防止其他app調用, 這裡面應該是用一對app id 和secret加密成一個令牌來做驗證.從而可以限制api的調用.只要保護好secret,api就應該只能在你自己的應用內訪問了.

④ OAuth2.0原理和驗證流程分析

第三方授權就是，委託第三方來對既定的用戶進行鑒定，鑒定成功之後，下發信任憑證，信任憑證和用戶掛鉤，同時可以使用此憑證來去第三方平台，獲得該用戶開放的部分信息.
直白的說，就是將用戶授權的工作交給第三方來做，而自己只維護信任憑證，並且獲取用戶信息。就像我們的QQ和微博一樣，你在逛各大論壇的時候，總會有一種途徑就是第三方的App登陸。顯然這種驗證是要在第三方做的，而論壇只需要維護一個token，並且可以獲取你的個人信息，然而沒什麼軟用。你如果想用部分功能，還是得注冊，因為你相當於論壇只是一個有部分信息的遊客，而沒有成為它的用戶，這種手段可以看成是提高自己訪問量或轉化率的一種手段吧。其實這種授權方案不一樣只用在互聯網，部分企業級的網站做資源的共享訪問也是這么做的。比如兩個網站合作，A站點賬戶可以登陸B站點，B站點賬戶可以登陸A站點，這樣A站點就能拿到B站點相關資源，反過來也是。就做到了資源共享。
那麼這種授權是怎麼做的呢？到底安全不安全？那麼可能就要引出OAuth協議了。

首先OAuth只是一個授權協議，不是一個實現或是一個中間件。
OAuth1於2007年10月建立，之後又在2009年6月重新修訂和發布 http://oauth.net/core/1.0a/
OAuth1.0授權流程是什麼？

流程很復雜，因為OAuth需要保證授權碼和Token在傳輸的時候不被截取和篡改，所以使用了很多簽名反復的驗證。
OAuth1.0的問題：
反復的簽名，開放平台本來就面對開發者，但是反復的簽名導致開發的流程太過於復雜。
沒有引入回跳地址的判斷，導致會跳可能會篡改，這樣授權碼和Token會被Hack掉（1.0a的時候修復了這個漏洞）。
授權流程過於單一化。

OAuth2.0的引入：
抽象驗證流程
由於OAuth1過於復雜，之後對OAuth進行了改造引入了Oauth2.0。OAuth的授權過程如下：

(A) 客戶端從資源擁有者那裡請求授權。授權請求能夠直接發送給資源擁有者，或者間接地通過授權伺服器這樣的中介，而後者更為可取。

(B) 客戶端收到一個訪問許可，它代表由資源伺服器提供的授權。

(C) 客戶端使用它自己的私有證書到授權伺服器上驗證，並出示訪問許可，來請求一個訪問令牌。

(D) 授權伺服器驗證客戶端私有證書和訪問許可的有效性，如果驗證通過則分發一個訪問令牌。

(E) 客戶端通過出示訪問令牌向資源伺服器請求受保護資源。

(F) 資源伺服器驗證訪問令牌的有效性，如果驗證通過則響應這個資源請求。

上面只是一個抽象的驗證流程，根據上面的抽象流程演化出四種驗證模式：
授權碼模式
授權碼模式和上述的 抽象驗證模式流程比較相似：

(A) web客戶端通過將終端用戶的user-agent重定向到授權伺服器來發起這個流程。客戶端傳入它的客戶端標識符、請求作用域、本地狀態和一個重定向URI，在訪問被許可（或被拒絕）後授權伺服器會重新將終端用戶引導回這個URI。

(B) 授權伺服器驗證終端用戶（藉助於user-agent），並確定終端用戶是否許可客戶端的訪問請求。

(C) 假定終端用戶許可了這次訪問，授權伺服器會將user-agent重定向到之前提供的重定向URI上去。授權伺服器為客戶端傳回一個授權碼做獲取訪問令牌之用。

(D) 客戶端通過驗證並傳入上一步取得的授權碼從授權伺服器請求一個訪問令牌。（需要帶上ClientId和Secret，ClientId和Secret是通過平台授予）

(E) 授權伺服器驗證客戶端私有證書和授權碼的有效性並返回訪問令牌。

授權碼模式（implicit grant type）
User-Agent子態適用於客戶端不能保存客戶端私有證書的App（純客戶端App，無Server參與）。因為可純客戶端的程序不能保存密鑰

(A) 客戶端將user-agent引導到終端用戶授權endpoint。客戶端傳入它的客戶端標識符、請求作用域、本地狀態和一個重定向URI，在訪問被許可（或被拒絕）後授權伺服器會重新將終端用戶引導回這個URI。

(B) 授權伺服器驗證終端用戶（通過user-agent）並確認終端用戶是許可還是拒絕了客戶端的訪問請求。

(C) 如果終端用戶許可了這次訪問，那麼授權伺服器會將user-agent引導到之前提供的重定向URI。重定向URI會在URI片斷{譯者註：URI片斷是指URI中#號之後的內容}中包含訪問令牌。

(D) user-agent響應重定向指令，向web伺服器發送不包含URI片斷的請求。user-agent在本地保存URI片斷。

(E) web伺服器返回一個web頁面（通常是嵌入了腳本的HTML網頁），這個頁面能夠訪問完整的重定向URI，它包含了由user-agent保存的URI片斷，同時這個頁面能夠將包含在URI片斷中的訪問令牌（和其它參數）提取出來。

(F) user-agent在本地執行由web伺服器提供的腳本，該腳本提取出訪問令牌並將它傳遞給客戶端。

密碼模式
密碼模式就是將密碼託管給第三方App，但是必須要保證第三方App高度可信。

（A）用戶向客戶端提供用戶名和密碼。

（B）客戶端將用戶名和密碼發給認證伺服器，向後者請求令牌。

（C）認證伺服器確認無誤後，向客戶端提供訪問令牌。

客戶端模式
這種模式不需要終端用戶的參與，只是Client和Server端的交互。通常只用於Client狀態的獲取。

（A）客戶端向認證伺服器進行身份認證，並要求一個訪問令牌。

（B）認證伺服器確認無誤後，向客戶端提供訪問令牌。

授權流程
這里以授權碼方式流程說明，主要流程分為兩步，獲取授權碼和通過授權碼獲取資源票據：

（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：表示客戶端的當前狀態，可以指定任意值，認證伺服器會原封不動地返回這個值。

C步驟中，伺服器回應客戶端的URI，包含以下參數：
code：表示授權碼，必選項。該碼的有效期應該很短，通常設為10分鍾，客戶端只能使用該碼一次，否則會被授權伺服器拒絕。該碼與客戶端ID和重定向URI，是一一對應關系。
state：如果客戶端的請求中包含這個參數，認證伺服器的回應也必須一模一樣包含這個參數。

D步驟中，客戶端向認證伺服器申請令牌的HTTP請求，包含以下參數：
grant_type：表示使用的授權模式，必選項，此處的值固定為"authorization_code"。
code：表示上一步獲得的授權碼，必選項。
redirect_uri：表示重定向URI，必選項，且必須與A步驟中的該參數值保持一致。
client_id：表示客戶端ID，必選項。

E步驟中，認證伺服器發送的HTTP回復，包含以下參數：
access_token：表示訪問令牌，必選項。
token_type：表示令牌類型，該值大小寫不敏感，必選項，可以是bearer類型或mac類型。
expires_in：表示過期時間，單位為秒。如果省略該參數，必須其他方式設置過期時間。
refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項。
scope：表示許可權范圍，如果與客戶端申請的范圍一致，此項可省略。

資源訪問過程：
http://localhost:8082/oauth/server/resource/uname.do?access_token=
此處主要由資源服務方實現，對於access_token進行校驗。

token過期刷新過程：
客戶端使用「refresh_token」訪問許可類型和下列參數傳入刷新令牌：
refresh_token：
必需參數。與待刷新的訪問令牌相關聯的刷新令牌。
grant_type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&refresh_token=n4E9O119d
授權伺服器必須驗證客戶端私有證書（如果存在），驗證刷新令牌是否有效，以及驗證資源擁有者的授權是否仍然有效。如果請求有效，授權伺服器則發布一個訪問令牌響應，原來的Token失效。以後訪問必須使用新Token。

OAuth2看上去很美好，但是細心觀察其實還是有一些漏洞的。

參考資料：
http://blog.csdn.net/seccloud/article/details/8192707
http://www.justwinit.cn/post/8138/
https://blog.yorkxin.org/2013/09/30/oauth2-1-introction
人人網OAuth歷程: http://www.infoq.com/cn/presentations/dx-renren-authentication-authorization/

⑤ oauth2下第一方為什麼需要用戶授權

用戶使用oauth2授權登錄綁定手機號後，下次登錄時可以直接用oauth2登錄，這樣用戶操作更方便一些。
oauth的設計是用戶不向第三方暴露自己的登陸信息的情況下，授權第三方以自己的身份訪問一些資源。
oauth2的設計初衷是源於oauth1計算簽名的復雜度，希望進一步降低第三方開發者的開發門檻。