當前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導讀]文章轉(zhuǎn)載來源:www.jianshu.com/p/1f2d6e5126cb|背景本文會詳細描述兩種通用的保證API安全性的方法:OAuth2和JSONWebToken(JWT)假設:你已經(jīng)或者正在實現(xiàn)API;你正在考慮選擇一個合適的方法保證API的安全性;|JWT和OAuth2比...


文章轉(zhuǎn)載來源:www.jianshu.com/p/1f2d6e5126cb

| 背景

本文會詳細描述兩種通用的保證API安全性的方法:OAuth2和JSON Web Token (JWT)假設:
  • 你已經(jīng)或者正在實現(xiàn)API;
  • 你正在考慮選擇一個合適的方法保證API的安全性;

| JWT和OAuth2比較?

要比較JWT和OAuth2?首先要明白一點就是,這兩個根本沒有可比性,是兩個完全不同的東西。
  • JWT是一種認證協(xié)議JWT提供了一種用于發(fā)布接入令牌(Access Token),并對發(fā)布的簽名接入令牌進行驗證的方法。令牌(Token)本身包含了一系列聲明,應用程序可以根據(jù)這些聲明限制用戶對資源的訪問。
  • OAuth2是一種授權(quán)框架OAuth2是一種授權(quán)框架,提供了一套詳細的授權(quán)機制(指導)。用戶或應用可以通過公開的或私有的設置,授權(quán)第三方應用訪問特定資源。既然JWT和OAuth2沒有可比性,為什么還要把這兩個放在一起說呢?實際中確實會有很多人拿JWT和OAuth2作比較。標題里把這兩個放在一起,確實有誤導的意思。很多情況下,在討論OAuth2的實現(xiàn)時,會把JSON Web Token作為一種認證機制使用。這也是為什么他們會經(jīng)常一起出現(xiàn)。
先來搞清楚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是一種安全標準?;舅悸肪褪怯脩籼峁┯脩裘兔艽a給認證服務器,服務器驗證用戶提交信息信息的合法性;如果驗證成功,會產(chǎn)生并返回一個Token(令牌),用戶可以使用這個token訪問服務器上受保護的資源。一個token的例子:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
一個token包含三部分:

header.claims.signature
為了安全的在url中使用,所有部分都 base64 URL-safe進行編碼處理。Header頭部分頭部分簡單聲明了類型(JWT)以及產(chǎn)生簽名所使用的算法。

{??"alg"?:?"AES256",??"typ"?:?"JWT"}
Claims聲明聲明部分是整個token的核心,表示要發(fā)送的用戶詳細信息。有些情況下,我們很可能要在一個服務器上實現(xiàn)認證,然后訪問另一臺服務器上的資源;或者,通過單獨的接口來生成token,token被保存在應用程序客戶端(比如瀏覽器)使用。一個簡單的聲明(claim)的例子:{??"sub":?"1234567890",??"name":?"John?Doe",??"admin":?true}
Signature簽名簽名的目的是為了保證上邊兩部分信息不被篡改。如果嘗試使用Base64對解碼后的token進行修改,簽名信息就會失效。一般使用一個私鑰(private key)通過特定算法對Header和Claims進行混淆產(chǎn)生簽名信息,所以只有原始的token才能與簽名信息匹配。? ?這里有一個重要的實現(xiàn)細節(jié)。只有獲取了私鑰的應用程序(比如服務器端應用)才能完全認證token包含聲明信息的合法性。所以,永遠不要把私鑰信息放在客戶端(比如瀏覽器)。

| OAuth2是什么?

相反,OAuth2不是一個標準協(xié)議,而是一個安全的授權(quán)框架。它詳細描述了系統(tǒng)中不同角色、用戶、服務前端應用(比如API),以及客戶端(比如網(wǎng)站或移動App)之間怎么實現(xiàn)相互認證。

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認證授權(quán)認證授權(quán)代表資源擁有者授權(quán)給客戶端應用程序的一組權(quán)限,可以是下邊幾種形式:
  • 授權(quán)碼
  • 隱式授權(quán)
  • 資源擁有者密碼證書
  • 客戶端證書
  • Endpoints終端
OAuth2框架需要下邊幾種終端:
  • 認證終端
  • Token終端
  • 重定向終端
從上邊這些應該可以看出,OAuth2定義了一組相當復雜的規(guī)范。

使用HTTPS保護用戶密碼

在進一步討論OAuth2和JWT的實現(xiàn)之前,有必要說一下,兩種方案都需要SSL安全保護,也就是對要傳輸?shù)臄?shù)據(jù)進行加密編碼。? ?安全地傳輸用戶提供的私密信息,在任何一個安全的系統(tǒng)里都是必要的。否則任何人都可以通過侵入私人wifi,在用戶登錄的時候竊取用戶的用戶名和密碼等信息。一些重要的實施考慮在做選擇之前,參考一下下邊提到的幾點。時間投入OAuth2是一個安全框架,描述了在各種不同場景下,多個應用之間的授權(quán)問題。有海量的資料需要學習,要完全理解需要花費大量時間。甚至對于一些有經(jīng)驗的開發(fā)工程師來說,也會需要大概一個月的時間來深入理解OAuth2。這是個很大的時間投入。相反,JWT是一個相對輕量級的概念。可能花一天時間深入學習一下標準規(guī)范,就可以很容易地開始具體實施。出現(xiàn)錯誤的風險OAuth2不像JWT一樣是一個嚴格的標準協(xié)議,因此在實施過程中更容易出錯。盡管有很多現(xiàn)有的庫,但是每個庫的成熟度也不盡相同,同樣很容易引入各種錯誤。在常用的庫中也很容易發(fā)現(xiàn)一些安全漏洞。當然,如果有相當成熟、強大的開發(fā)團隊來持續(xù)OAuth2實施和維護,可以一定程度上避免這些風險。社交登錄的好處在很多情況下,使用用戶在大型社交網(wǎng)站的已有賬戶來認證會方便。如果期望你的用戶可以直接使用Facebook或者Gmail之類的賬戶,使用現(xiàn)有的庫會方便得多。

| 結(jié)論

做結(jié)論前,我們先來列舉一下 ?JWT和OAuth2的主要使用場景。

JWT使用場景

無狀態(tài)的分布式API
JWT的主要優(yōu)勢在于使用無狀態(tài)、可擴展的方式處理應用中的用戶會話。服務端可以通過內(nèi)嵌的聲明信息,很容易地獲取用戶的會話信息,而不需要去訪問用戶或會話的數(shù)據(jù)庫。在一個分布式的面向服務的框架中,這一點非常有用。? ?但是,如果系統(tǒng)中需要使用黑名單實現(xiàn)長期有效的token刷新機制,這種無狀態(tài)的優(yōu)勢就不明顯了。優(yōu)勢
  • 快速開發(fā)
  • 不需要cookie
  • JSON在移動端的廣泛應用
  • 不依賴于社交登錄
  • 相對簡單的概念理解
限制
  • Token有長度限制
  • Token不能撤銷
  • 需要token有失效時間限制(exp)
  • OAuth2使用場景

| 在作者看來兩種比較有必要使用OAuth2的場景:

外包認證服務器
上邊已經(jīng)討論過,如果不介意API的使用依賴于外部的第三方認證提供者,你可以簡單地把認證工作留給認證服務商去做。也就是常見的,去認證服務商(比如facebook)那里注冊你的應用,然后設置需要訪問的用戶信息,比如電子郵箱、姓名等。用戶訪問站點的注冊頁面時,會看到連接到第三方提供商的入口。用戶點擊以后被重定向到對應的認證服務商網(wǎng)站,獲得用戶的授權(quán)后就可以訪問到需要的信息,然后重定向回來。優(yōu)勢
  • 快速開發(fā)
  • 實施代碼量小
  • 維護工作減少
大型企業(yè)解決方案
如果設計的API要被不同的App使用,并且每個App使用的方式也不一樣,使用OAuth2是個不錯的選擇。考慮到工作量,可能需要單獨的團隊,針對各種應用開發(fā)完善、靈活的安全策略。當然需要的工作量也比較大!這一點,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

優(yōu)勢

  • 靈活的實現(xiàn)方式

  • 可以和JWT同時使用

  • 可針對不同應用擴展
參考:
  • http://jwt.io - JWT官方網(wǎng)站,也可以查看到使用不同語言實現(xiàn)的庫的狀態(tài)。
  • http://oauth.net/2/ OAuth2官方網(wǎng)站, 也也可以查看到使用不同語言實現(xiàn)的庫的狀態(tài)。
  • 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.

本站聲明: 本文章由作者或相關機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
關閉
關閉