django jwt認證機制原理詳解
幾種常用的認證機制
轉載：https://segmentfault.com/a/1190000010312468
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由 . 分為三段，通過解碼可以得到：
1. 頭部（Header）
// 包括類別（typ）、加密演算法（alg）；
{
"alg": "HS256",
"typ": "JWT"
}jwt的頭部包含兩部分資訊：
宣告型別，這裡是jwt
宣告加密的演算法 通常直接使用 HMAC SHA256
然後將頭部進行base64加密（該加密是可以對稱解密的)，構成了第一部分。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ92. 載荷（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 編碼，所以第二部分的資料實際上是明文的。我們應該避免在這裡存放不能公開的隱私資訊。
3. 簽名（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實踐
使用比較方便，下邊是我在應用中使用的例子：
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