轉自：樂傻驢
鏈接：www.jianshu.com/p/1f2d6e5126cb
本文會詳細描述兩種通用的保證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訪問服務器上受保護的資源，
一個token的例子:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
一個token包含三部分：
header.claims.signature
了安全的在url中使用，所有部分都 base64 URL-safe進行編碼處理，
Header頭部分
頭部分簡單宣告了型別(JWT)以及產生簽名所使用的演算法，
{ "alg" : "AES256", "typ" : "JWT"}
Claims宣告
? 宣告部分是整個token的核心，表示要發送的用戶詳細資訊，有些情況下，我們很可能要在一個服務器上實作認證，然后訪問另一臺服務器上的資源；或者，通過單獨的介面來生成token，token被保存在應用程式客戶端（比如瀏覽器）使用，
一個簡單的宣告（claim）的例子：
{ "sub": "1234567890", "name": "John Doe", "admin": true}
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.
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什么新語法？
4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/350678.html
標籤：Java