最近想做個小程序，需要用到授權認證流程。以前項目都是用的 OAuth2 認證，但是Sanic 使用OAuth2 不太方便，就想試一下 JWT 的認證方式。
這一篇主要內容是 JWT 的認證原理，以及python 使用 jwt 認識的實踐。
幾種常用的認證機制
HTTP Basic Auth
HTTP Basic Auth 在HTTP中，基本認證是一種用來允許Web瀏覽器或其他客戶端程序在請求時提供用戶名和口令形式的身份憑證的一種登錄驗證方式，通常用戶名和明碼會通過HTTP頭傳遞。
在發送之前是以用戶名追加一個冒號然後串接上口令，並將得出的結果字符串再用Base64算法編碼。例如，提供的用戶名是Aladdin、口令是open sesame，則拼接後的結果就是Aladdin:open sesame，然後再將其用Base64編碼，得到QWxhZGRpbjpvcGVuIHNlc2FtZQ==。最終將Base64編碼的字符串發送出去，由接收者解碼得到一個由冒號分隔的用戶名和口令的字符串。
優點：
基本認證的一個優點是基本上所有流行的網頁瀏覽器都支持基本認證。
缺點：
由於用戶名和密碼都是Base64編碼的，而Base64編碼是可逆的，所以用戶名和密碼可以認爲是明文。所以只有在客戶端和服務器主機之間的連接是安全可信的前提下才可以使用。
接下來我們看一個更加安全也適用範圍更大的認證方式 OAuth。
OAuth
OAuth 是一個關於授權（authorization）的開放網絡標準。允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。現在的版本是2.0版。
嚴格來說，OAuth2不是一個標準協議，而是一個安全的授權框架。它詳細描述了系統中不同角色、用戶、服務前端應用（比如API），以及客戶端（比如網站或移動App）之間怎麼實現相互認證。
名詞定義：
- Third-party application: 第三方應用程序，又稱"客戶端"（client）
- HTTP service：HTTP服務提供商
- Resource Owner：資源所有者，通常稱"用戶"（user）。
- User Agent：用戶代理，比如瀏覽器。
- Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。
- Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一臺服務器，也可以是不同的服務器。
OAuth 2.0 運行流程如圖：
（A）用戶打開客戶端以後，客戶端要求用戶給予授權。
（B）用戶同意給予客戶端授權。
（C）客戶端使用上一步獲得的授權，向認證服務器申請令牌。
（D）認證服務器對客戶端進行認證以後，確認無誤，同意發放令牌。
（E）客戶端使用令牌，向資源服務器申請獲取資源。
（F）資源服務器確認令牌無誤，同意向客戶端開放資源。
優點:
快速開發
實施代碼量小
維護工作減少
如果設計的API要被不同的App使用，並且每個App使用的方式也不一樣，使用OAuth2是個不錯的選擇。
缺點:
OAuth2是一個安全框架，描述了在各種不同場景下，多個應用之間的授權問題。有海量的資料需要學習，要完全理解需要花費大量時間。
OAuth2不是一個嚴格的標準協議，因此在實施過程中更容易出錯。
瞭解了以上兩種方式後，現在終於到了本篇的重點，JWT 認證。
JWT認證
Json web token (JWT), 根據官網的定義，是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519).該token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。
JWT特點
- 體積小，因而傳輸速度快
- 傳輸方式多樣，可以通過URL/POST參數/HTTP頭部等方式傳輸
- 嚴格的結構化。它自身（在 payload 中）就包含了所有與用戶相關的驗證消息，- - 如用戶可訪問路由、訪問有效期等信息，服務器無需再去連接數據庫驗證信息的有效性，並且 payload 支持爲你的應用而定製化。
- 支持跨域驗證，可以應用於單點登錄。
JWT原理
JWT是Auth0提出的通過對JSON進行加密簽名來實現授權驗證的方案，編碼之後的JWT看起來是這樣的一串字符：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
由.分爲三段，通過解碼可以得到：
- 頭部（Header）
// 包括類別（typ）、加密算法（alg）；
{
"alg": "HS256",
"typ": "JWT"
}
jwt的頭部包含兩部分信息：
- 聲明類型，這裏是jwt
- 聲明加密的算法 通常直接使用 HMAC SHA256
然後將頭部進行base64加密（該加密是可以對稱解密的)，構成了第一部分。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
- 載荷（payload)
載荷就是存放有效信息的地方。這些有效信息包含三個部分：
- 標準中註冊聲明
- 公共的聲名
- 私有的聲明
公共的聲明：
公共的聲明可以添加任何的信息，一般添加用戶的相關信息或其他業務需要的必要信息.但不建議添加敏感信息，因爲該部分在客戶端可解密。
私有的聲明 ：
私有聲明是提供者和消費者所共同定義的聲明，一般不建議存放敏感信息，因爲base64是對稱解密的，意味着該部分信息可以歸類爲明文信息。
下面是一個例子：
// 包括需要傳遞的用戶信息；
{
"iss": "Online JWT Builder",
"iat": 1416797419,
"exp": 1448333419,
"aud": "www.gusibi.com",
"sub": "uid",
"nickname": "goodspeed",
"username": "goodspeed",
"scopes": [ "admin", "user" ]
}
- iss: 該JWT的簽發者，是否使用是可選的；
- sub: 該JWT所面向的用戶，是否使用是可選的；
- aud: 接收該JWT的一方，是否使用是可選的；
- exp(expires): 什麼時候過期，這裏是一個Unix時間戳，是否使用是可選的；
- iat(issued at): 在什麼時候簽發的(UNIX時間)，是否使用是可選的；
其他還有：
- nbf (Not Before)：如果當前時間在nbf裏的時間之前，則Token不被接受；一般都會留一些餘地，比如幾分鐘；，是否使用是可選的；
- jti: jwt的唯一身份標識，主要用來作爲一次性token，從而回避重放攻擊。
將上面的JSON對象進行base64編碼可以得到下面的字符串。這個字符串我們將它稱作JWT的Payload（載荷）。
eyJpc3MiOiJPbmxpbmUgSldUIEJ1aWxkZXIiLCJpYXQiOjE0MTY3OTc0MTksImV4cCI6MTQ0ODMzMzQxOSwiYXVkIjoid3d3Lmd1c2liaS5jb20iLCJzdWIiOiIwMTIzNDU2Nzg5Iiwibmlja25hbWUiOiJnb29kc3BlZWQiLCJ1c2VybmFtZSI6Imdvb2RzcGVlZCIsInNjb3BlcyI6WyJhZG1pbiIsInVzZXIiXX0
信息會暴露：由於這裏用的是可逆的base64 編碼，所以第二部分的數據實際上是明文的。我們應該避免在這裏存放不能公開的隱私信息。
- 簽名（signature)
// 根據alg算法與私有祕鑰進行加密得到的簽名字串；
// 這一段是最重要的敏感信息，只能在服務端解密；
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
SECREATE_KEY
)
jwt的第三部分是一個簽證信息，這個簽證信息由三部分組成：
- header (base64後的)
- payload (base64後的)
- secret
將上面的兩個編碼後的字符串都用句號.連接在一起（頭部在前），就形成了:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9
最後，我們將上面拼接完的字符串用HS256算法進行加密。在加密的時候，我們還需要提供一個密鑰（secret）。如果我們用 secret 作爲密鑰的話，那麼就可以得到我們加密後的內容:
pq5IDv-yaktw6XEa5GEv07SzS9ehe6AcVSdTj0Ini4o
將這三部分用.連接成一個完整的字符串,構成了最終的jwt:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJPbmxpbmUgSldUIEJ1aWxkZXIiLCJpYXQiOjE0MTY3OTc0MTksImV4cCI6MTQ0ODMzMzQxOSwiYXVkIjoid3d3Lmd1c2liaS5jb20iLCJzdWIiOiIwMTIzNDU2Nzg5Iiwibmlja25hbWUiOiJnb29kc3BlZWQiLCJ1c2VybmFtZSI6Imdvb2RzcGVlZCIsInNjb3BlcyI6WyJhZG1pbiIsInVzZXIiXX0.pq5IDv-yaktw6XEa5GEv07SzS9ehe6AcVSdTj0Ini4o
簽名的目的：簽名實際上是對頭部以及載荷內容進行簽名。所以，如果有人對頭部以及載荷的內容解碼之後進行修改，再進行編碼的話，那麼新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道服務器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。
這樣就能保證token不會被篡改。
token 生成好之後，接下來就可以用token來和服務器進行通訊了。
下圖是client 使用 JWT 與server 交互過程:
這裏在第三步我們得到 JWT 之後，需要將JWT存放在 client，之後的每次需要認證的請求都要把JWT發送過來。（請求時可以放到 header 的 Authorization ）
JWT 使用場景
JWT的主要優勢在於使用無狀態、可擴展的方式處理應用中的用戶會話。服務端可以通過內嵌的聲明信息，很容易地獲取用戶的會話信息，而不需要去訪問用戶或會話的數據庫。在一個分佈式的面向服務的框架中，這一點非常有用。
但是，如果系統中需要使用黑名單實現長期有效的token刷新機制，這種無狀態的優勢就不明顯了。
優點
快速開發
不需要cookie
JSON在移動端的廣泛應用
不依賴於社交登錄
相對簡單的概念理解
缺點
Token有長度限制
Token不能撤銷
需要token有失效時間限制(exp)
python 使用JWT實踐
我基本是使用 python 作爲服務端語言，我們可以使用 pyjwt：https://github.com/jpadilla/pyjwt/
使用比較方便，下邊是我在應用中使用的例子：
import jwt
import time
# 使用 sanic 作爲restful api 框架
def create_token(request):
grant_type = request.json.get('grant_type')
username = request.json['username']
password = request.json['password']
if grant_type == 'password':
account = verify_password(username, password)
elif grant_type == 'wxapp':
account = verify_wxapp(username, password)
if not account:
return {}
payload = {
"iss": "gusibi.com",
"iat": int(time.time()),
"exp": int(time.time()) + 86400 * 7,
"aud": "www.gusibi.com",
"sub": account['_id'],
"username": account['username'],
"scopes": ['open']
}
token = jwt.encode(payload, 'secret', algorithm='HS256')
return True, {'access_token': token, 'account_id': account['_id']}
def verify_bearer_token(token):
# 如果在生成token的時候使用了aud參數，那麼校驗的時候也需要添加此參數
payload = jwt.decode(token, 'secret', audience='www.gusibi.com', algorithms=['HS256'])
if payload:
return True, token
return False, token
這裏，我們可以使用 jwt 直接生成 token，不用手動base64加密和拼接。
詳細代碼可以參考 gusibi/Metis: 一個測試類小程序（包含前後端代碼）。
這個項目中，api 使用 python sanic，文檔使用 swagger-py-codegen 生成，提供 swagger ui。
現在可以使用 swagger ui 來測試jwt。
總結
這一篇主要介紹了 jwt 的原理、驗證步驟，最後是使用 pyjwt 包演示 生成token以及校驗token的方法。