OAuth 2如何使用安全令牌防止重放攻擊等事情？

據我瞭解，OAuth 2中發生如下事件鏈，以便Site-A從Site-B訪問用戶的信息。

1. Site-A在Site-B上註冊，並獲取Secret和ID。
2. 當用戶告訴Site-A訪問Site-B ， 用戶被髮送到Site-B ，他們告訴Site-B他們確實但願爲特定信息授予Site-A權限。
3. Site-B將用戶重定向回Site-A以及受權碼。
4. 而後， Site-A將該受權碼及其祕密傳遞迴Site-B以換取安全令牌。
5. Site-A而後發出請求到Site-B與請求一塊兒捆綁安全令牌表明用戶的。

全部這些在高級別上如何在安全性和加密方面起做用？ OAuth 2如何使用安全令牌防止重放攻擊等事情？

---

#1樓

另外一個答案很是詳細，解決了OP提出的大部分問題。

爲了詳細闡述，特別是解決OP的問題「OAuth 2如何使用安全令牌保護重放攻擊？」，在實施 OAuth 2的官方建議中還有兩個額外的保護措施：

1）代幣一般有一個短暫的有效期（ http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ）：

令牌的短暫到期時間是防範如下威脅的一種方法：

• 重播...

2）當站點A使用令牌時，建議不會將其顯示爲URL參數，而是顯示在受權請求頭字段（ http://tools.ietf.org/html/rfc6750 ）中：

客戶端應該使用帶有「承載」HTTP受權方案的「受權」請求頭字段，使用承載令牌進行通過身份驗證的請求。 ...

除了在參與瀏覽器無權訪問「受權」請求標頭字段的應用程序上下文中，不該使用「application / x-www-form-urlencoded」方法。 ...

包含URI查詢參數...以記錄當前使用狀況; 因爲其安全性不足，不建議使用它

---

#2樓

OAuth是一種協議，三方應用程序可使用該協議訪問存儲在另外一個網站中的數據而無需您的賬戶和密碼。 有關更官方的定義，請參閱Wiki或規範。

這是一個用例演示：

1. 我登陸LinkedIn並想要鏈接個人Gmail聯繫人中的一些朋友。 LinkedIn支持這一點。 它將從gmail請求安全資源（個人gmail聯繫人列表）。 因此我點擊這個按鈕：
   

2. 當我輸入個人賬戶和密碼時，會彈出一個網頁，並顯示Gmail登陸頁面：
   

3. 而後，Gmail會顯示一個贊成頁面，點擊「接受」：

4. 如今LinkedIn能夠訪問Gmail中的聯繫人：

如下是上面示例的流程圖：

第1步：LinkedIn從Gmail的受權服務器請求令牌。

第2步：Gmail受權服務器對資源全部者進行身份驗證，並向用戶顯示贊成頁面。 （若是用戶還沒有登陸，則須要登陸Gmail）

第3步：用戶授予LinkedIn訪問Gmail數據的請求。

第4步：Gmail受權服務器使用訪問令牌回覆。

第5步：LinkedIn使用此訪問令牌調用Gmail API。

第6步：若是訪問令牌有效，Gmail資源服務器會返回您的聯繫人。 （該令牌將由Gmail資源服務器驗證）

您能夠在此處獲取有關OAuth的詳細信息。

---

#3樓

OAuth 2.0如何在現實生活中發揮做用：

當我在窗口看到最美味的甜甜圈時，我正在去奧拉夫的麪包店開車去工做 - 個人意思是，那東西正在滴下巧克力的美味。 因此我進去了，並要求「我必須有那個甜甜圈！」。 他說「確定會是30美圓。」

是的，我知道，一個甜甜圈30美圓！ 必定很好吃！ 當我忽然聽到廚師大喊「不！沒有甜甜圈給你」時，我伸手去拿錢包。 我問：爲何？ 他說他只接受銀行轉帳。

真的嗎？ 是的，他很認真。 我差點就走了，而後甜甜圈叫我：「吃我，我好吃......」。 我是誰不遵照甜甜圈的命令？ 我說了能夠。

他遞給我一張帶有他名字的便條（廚師，而不是甜甜圈）：「告訴他們奧拉夫送你的」。 他的名字已經在筆記上了，因此我不知道那是什麼意思，可是好的。

我開了一個半小時到個人銀行。 我把票據遞給了出納員; 我告訴她奧拉夫送個人。 她給了我其中一個外表，那種說「我能看懂」。

她接過個人筆記，問個人身份，問我能夠給他多少錢。 我告訴她30美圓。 她作了一些塗鴉並遞給我另外一張紙條。 這個上面有一堆數字，我猜他們是如何跟蹤筆記的。

那時我正在捱餓。 我趕忙離開那裏，一個半小時後我回來了，站在奧拉夫面前，個人筆記延長了。 他接過它，看着它說：「我會回來的」。

我覺得他正在吃甜甜圈，但30分鐘後我就開始懷疑了。 因此我問櫃檯後面的那我的「奧拉夫在哪裏？」。 他說「他去賺錢」。 「你什麼意思？」。 「他注意到銀行」。

嗯......因此奧拉夫接過銀行給個人說明，而後回到銀行從個人賬戶中取錢。 因爲他收到了銀行給個人那張紙條，銀行知道他就是那個我正在談論的那我的，並且由於我跟銀行說話，他們知道只給他30美圓。

我花了很長時間才弄明白這一點，由於當我擡起頭來的時候，奧拉夫站在我面前， 最後遞給我甜甜圈。 在我離開以前，我不得不問：「奧拉夫，你老是以這種方式賣甜甜圈嗎？」 「不，我曾經作過不一樣的事情。」

呵呵。 當我走回個人車時，個人電話響了。 我沒有打擾回答，這多是個人工做要求解僱我，個人老闆是這樣的***。 此外，我被捲入思考我剛剛經歷的過程。

個人意思是考慮一下：我可以讓Olaf從個人銀行帳戶中拿走30美圓而沒必要向他提供個人帳戶信息。 並且我沒必要擔憂他會花太多錢，由於我已經告訴銀行他只能拿走30美圓。 銀行知道他是合適的人，由於他有他們給我給Olaf的那張便條。

好吧，我寧願把口袋裏的30美圓遞給他。 可是如今他有那個說明我能夠告訴銀行讓他每週花30美圓，而後我就能夠出如今麪包店並且我沒必要再去銀行了。 若是我願意，我甚至能夠經過電話訂購甜甜圈。

固然我永遠不會那樣作 - 甜甜圈很噁心。

我想知道這種方法是否有更普遍的應用。 他提到這是他的第二種方法，我能夠稱之爲Olaf 2.0。 無論怎樣，我最好回家，我得開始尋找新工做。 可是，在我從鎮上的新地方獲得其中一種草莓奶昔以前，我須要一些東西來洗去那個甜甜圈的味道。

---

#4樓

圖1，取自RFC6750 ：

+--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

---

#5樓

這就是Oauth 2.0的工做原理，在本文中有很好的解釋