OAuth 2和JWT - 如何設計安全的API？
OAuth 2和JWT - 如何設計安全的API？
Moakap譯，原文 OAuth 2 VS JSON Web Tokens: How to secure an API
本文會詳細描述兩種通用的保證API安全性的方法：OAuth2和JSON Web Token (JWT)
假設：
- 你已經或者正在實現API；
- 你正在考慮選擇一個合適的方法保證API的安全性；
JWT和OAuth2比較？
要比較JWT和OAuth2？首先要明白一點就是，這兩個根本沒有可比性，是兩個完全不同的東西。
-
JWT是一種認證協議
JWT提供了一種用於發布接入令牌（Access Token),並對發布的簽名接入令牌進行驗證的方法。 令牌（Token）本身包含了一系列聲明，應用程序可以根據這些聲明限制用戶對資源的訪問。 -
OAuth2是一種授權框架
另一方面，OAuth2是一種授權框架，提供了一套詳細的授權機制（指導）。用戶或應用可以通過公開的或私有的設置，授權第三方應用訪問特定資源。
既然JWT和OAuth2沒有可比性，為什麽還要把這兩個放在一起說呢？實際中確實會有很多人拿JWT和OAuth2作比較。標題裏把這兩個放在一起，確實有誤導的意思。很多情況下，在討論OAuth2的實現時，會把JSON Web Token作為一種認證機制使用。這也是為什麽他們會經常一起出現。
先來搞清楚JWT和OAuth2究竟是幹什麽的～
JSON Web Token (JWT)
JWT在標準中是這麽定義的：
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).
- RFC7519 https://tools.ietf.org/html/rfc7519
JWT是一種安全標準。基本思路就是用戶提供用戶名和密碼給認證服務器，服務器驗證用戶提交信息信息的合法性；如果驗證成功，會產生並返回一個Token（令牌），用戶可以使用這個token訪問服務器上受保護的資源。
一個toke的例子：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ- 1
一個token包含三部分：
header.claims.signature
為了安全的在url中使用，所有部分都base64 URL-safe進行編碼處理。
Header頭部分
頭部分簡單聲明了類型(JWT)以及產生簽名所使用的算法。
{
"alg" : "AES256",
"typ" : "JWT"
}- 1
- 2
- 3
- 4
Claims聲明
聲明部分是整個token的核心，表示要發送的用戶詳細信息。有些情況下，我們很可能要在一個服務器上實現認證，然後訪問另一臺服務器上的資源；或者，通過單獨的接口來生成token，token被保存在應用程序客戶端（比如瀏覽器）使用。
一個簡單的聲明（claim）的例子：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}- 1
- 2
- 3
- 4
- 5
Signature簽名
簽名的目的是為了保證上邊兩部分信息不被篡改。如果嘗試使用Bas64對解碼後的token進行修改，簽名信息就會失效。一般使用一個私鑰（private key）通過特定算法對Header和Claims進行混淆產生簽名信息，所以只有原始的token才能於簽名信息匹配。
這裏有一個重要的實現細節。只有獲取了私鑰的應用程序（比如服務器端應用）才能完全認證token包含聲明信息的合法性。所以，永遠不要把私鑰信息放在客戶端（比如瀏覽器）。
OAuth2是什麽？
相反，OAuth2不是一個標準協議，而是一個安全的授權框架。它詳細描述了系統中不同角色、用戶、服務前端應用（比如API），以及客戶端（比如網站或移動App）之間怎麽實現相互認證。
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
- RFC6749 https://tools.ietf.org/html/rfc6749
這裏簡單說一下涉及到的基本概念。
Roles角色
應用程序或者用戶都可以是下邊的任何一種角色：
- 資源擁有者
- 資源服務器
- 客戶端應用
- 認證服務器
Client Types客戶端類型
這裏的客戶端主要指API的使用者。它可以是的類型：
- 私有的
- 公開的
Client Profile客戶端描述
OAuth2框架也指定了集中客戶端描述，用來表示應用程序的類型：
- Web應用
- 用戶代理
- 原聲應用
Authorization Grants認證授權
認證授權代表資源擁有者授權給客戶端應用程序的一組權限，可以是下邊幾種形式：
- 授權碼
- 隱式授權
- 資源擁有者密碼證書
- 客戶端證書
Endpoints終端
OAuth2框架需要下邊幾種終端：
- 認證終端
- Token終端
- 重定向終端
從上邊這些應該可以看出，OAuth2定義了一組相當復雜的規範。
使用HTTPS保護用戶密碼
在進一步討論OAuth2和JWT的實現之前，有必要說一下，兩種方案都需要SSL安全保護，也就是對要傳輸的數據進行加密編碼。
安全地傳輸用戶提供的私密信息，在任何一個安全的系統裏都是必要的。否則任何人都可以通過侵入私人wifi，在用戶登錄的時候竊取用戶的用戶名和密碼等信息。
一些重要的實施考慮
在做選擇之前，參考一下下邊提到的幾點。
時間投入
OAuth2是一個安全框架，描述了在各種不同場景下，多個應用之間的授權問題。有海量的資料需要學習，要完全理解需要花費大量時間。甚至對於一些有經驗的開發工程師來說，也會需要大概一個月的時間來深入理解OAuth2。 這是個很大的時間投入。
相反，JWT是一個相對輕量級的概念。可能花一天時間深入學習一下標準規範，就可以很容易地開始具體實施。
出現錯誤的風險
OAuth2不像JWT一樣是一個嚴格的標準協議，因此在實施過程中更容易出錯。盡管有很多現有的庫，但是每個庫的成熟度也不盡相同，同樣很容易引入各種錯誤。在常用的庫中也很容易發現一些安全漏洞。
當然，如果有相當成熟、強大的開發團隊來持續OAuth2實施和維護，可以一定成都上避免這些風險。
社交登錄的好處
在很多情況下，使用用戶在大型社交網站的已有賬戶來認證會方便。
如果期望你的用戶可以直接使用Facebook或者Gmail之類的賬戶，使用現有的庫會方便得多。
結論
做結論前，我們先來列舉一下JWT和OAuth2的主要使用場景。
JWT使用場景
無狀態的分布式API
JWT的主要優勢在於使用無狀態、可擴展的方式處理應用中的用戶會話。服務端可以通過內嵌的聲明信息，很容易地獲取用戶的會話信息，而不需要去訪問用戶或會話的數據庫。在一個分布式的面向服務的框架中，這一點非常有用。
但是，如果系統中需要使用黑名單實現長期有效的token刷新機制，這種無狀態的優勢就不明顯了。
優勢
- 快速開發
- 不需要cookie
- JSON在移動端的廣泛應用
- 不依賴於社交登錄
- 相對簡單的概念理解
限制
- Token有長度限制
- Token不能撤銷
- 需要token有失效時間限制(exp)
OAuth2使用場景
在作者看來兩種比較有必要使用OAuth2的場景：
外包認證服務器
上邊已經討論過，如果不介意API的使用依賴於外部的第三方認證提供者，你可以簡單地把認證工作留給認證服務商去做。
也就是常見的，去認證服務商（比如facebook）那裏註冊你的應用，然後設置需要訪問的用戶信息，比如電子郵箱、姓名等。當用戶訪問站點的註冊頁面時，會看到連接到第三方提供商的入口。用戶點擊以後被重定向到對應的認證服務商網站，獲得用戶的授權後就可以訪問到需要的信息，然後重定向回來。
優勢
- 快速開發
- 實施代碼量小
- 維護工作減少
大型企業解決方案
如果設計的API要被不同的App使用，並且每個App使用的方式也不一樣，使用OAuth2是個不錯的選擇。
考慮到工作量，可能需要單獨的團隊，針對各種應用開發完善、靈活的安全策略。當然需要的工作量也比較大！這一點，OAuth2的作者也指出過：
To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation. However, at the hands of most developers – as has been the experience from the past two years – 2.0 is likely to produce insecure implementations.
hueniverse - OAuth 2.0 and the Road to Hell
優勢
- 靈活的實現方式
- 可以和JWT同時使用
- 可針對不同應用擴展
進一步
- http://jwt.io - JWT官方網站，也可以查看到使用不同語言實現的庫的狀態。
- http://oauth.net/2/ OAuth2官方網站, 也也可以查看到使用不同語言實現的庫的狀態。
- OAuth 2 tutorials - Useful overview of how OAuth 2 works
- Oauth2 Spec issues Eran Hammer’s (推進OAuth標準的作者) views on what went wrong with the OAuth 2 spec process. Whatever your own opinion, good to get some framing by someone who understand’s key aspects of what make a security standard successful.
- Thoery and implemnetation: with Laravel and Angular Really informative guide to JWT in theory and in practice for Laravel and Angular.
OAuth 2和JWT - 如何設計安全的API？