3種基礎的 REST 安全機制

安全是 RESTful web service 的基石，咱們主要討論如下3種主要的方法：

• Basic authentication
• Oauth 2.0
• Oauth 2.0 + JWT

1. Basic authentication

這是最古老、最簡單的方法。

形式

username + password + Base64。

工做機制

假設一個用戶要登陸 Facebook 帳號，查看：feed 流、消息、好友、組，這4個服務都是獨立的。

用戶提交用戶名密碼以後，系統驗證後容許進入，然而系統是不知道其角色和權限的，例如什麼服務容許訪問。

因此，每次用戶訪問任何服務時，系統須要再次驗證是否容許這次操做，這意味着須要一次對受權服務器的額外調用。例如上面的4個服務，那麼每一個用戶就會有4次額外調用。

如今想象每秒咱們有 3000 個用戶訪問，乘以4個服務，結果就是每秒 12000 次受權服務器調用。

結論

可擴展性差，有大量的沒有商業價值的額外調用，顯著增長了服務器的壓力。

2. Oauth 2.0

形式

username + password + access token + expiration token

工做機制

用戶使用用戶名密碼登陸系統以後，會收到一對 token，一個 access token 和一個 refresh token。

access token 用於訪問全部服務，過時時，使用 refresh token 產生一對新的 token。

若是一個用戶天天都進入系統，token 會天天更新，沒必要每次使用用戶名密碼登陸。

refresh token 也有過時週期，過時後須要再次使用用戶名密碼登陸。

Oauth 2.0 用來替換 Basic authentication，有其明顯的優點，例如用戶沒必要每次都提交用戶名密碼，然而，系統仍然須要調用受權服務器，來檢查 token 所屬用戶能作的操做。

假設過時時間是一天，能夠大大減小登陸服務器的負載，由於一個用戶一天只須要登陸驗證一次，而不是每次進入系統時都須要。

可是，系統仍然須要去存儲狀態的地方去驗證每一個 token，查看用戶的角色。

因此，最後仍是須要屢次調用受權服務器。

結論

和 Basic authentication 有一樣的問題，擴展性差，受權服務器會有大量負載。

OAuth 2 + Json Web Tokens

形式

username + password + JSON map + Base64 + private key + expiration date

工做機制

用戶第一次使用用戶名密碼登陸系統後，系統不只返回一個 access token，並且還有一個 JSON map，其中包含全部的用戶信息，例如角色和權限，這些信息是使用 Base64 編碼的，並使用私鑰加密。

在 token 中存儲了狀態信息，使服務是無狀態的。

用戶本身拿着本身的信息，全部信息都在 token 裏面，因此就不須要額外的調用了。

這對減小服務器的負載起到了巨大的做用，如今這個方法在世界範圍內被普遍使用。

結論

擴展性好，很是適合微服務。

亞馬遜的作法

在用戶建立亞馬遜帳號的時候，會生成一個永久的、超級安全的 access token，須要用戶保護好。

當用戶須要請求亞馬遜的時候，須要使用這個私有的 token 對 HTTP header 數據進行簽名，並添加到 header 中一塊兒發送過去。

服務器端，亞馬遜也有用戶的這個私有 token，接收到用戶的請求後，一樣對 header 進行簽名，而後和用戶的簽名進行比較，如何相同，則容許訪問。

最大的好處就是隻須要發送一次用戶名密碼，用於獲取 token，並且使用簽名機制很是安全，不在意消息被攔截。

翻譯自：

https://medium.com/@yellow/re...

推薦閱讀：

• 高併發的經常使用策略
• 接口級故障處理策略
• 負載均衡的分類及算法
• 異地多活架構
• 架構設計 -- 服務降級