drf之JWT認證
一 JWT認證
在使用者註冊或登入後,我們想記錄使用者的登入狀態,或者為使用者建立身份認證的憑證。我們不再使用Session認證機制,而使用Json Web Token(本質就是token)認證機制。
|
|
1.1 構成和工作原理
JWT的構成
JWT就是一段字串,由三段資訊構成的,將這三段資訊文字用.
連結一起就構成了Jwt字串。就像這樣:
|
|
第一部分我們稱它為頭部(header),第二部分我們稱其為載荷(payload, 類似於飛機上承載的物品),第三部分是簽證(signature).
1.1.1 header
jwt的頭部承載兩部分資訊:
- 宣告型別,這裡是jwt
- 宣告加密的演算法 通常直接使用 HMAC SHA256
完整的頭部就像下面這樣的JSON:
|
|
然後將頭部進行base64加密(該加密是可以對稱解密的),構成了第一部分.
|
|
1.1.2 payload
載荷就是存放有效資訊的地方。這個名字像是特指飛機上承載的貨品,這些有效資訊包含三個部分
- 標準中註冊的宣告
- 公共的宣告
- 私有的宣告
標準中註冊的宣告 (建議但不強制使用) :
- iss: jwt簽發者
- sub: jwt所面向的使用者
- aud: 接收jwt的一方
- exp: jwt的過期時間,這個過期時間必須要大於簽發時間
- nbf: 定義在什麼時間之前,該jwt都是不可用的.
- iat: jwt的簽發時間
- jti: jwt的唯一身份標識,主要用來作為一次性token,從而回避時序攻擊。
公共的宣告 : 公共的宣告可以新增任何的資訊,一般新增使用者的相關資訊或其他業務需要的必要資訊.但不建議新增敏感資訊,因為該部分在客戶端可解密.
私有的宣告 : 私有宣告是提供者和消費者所共同定義的宣告,一般不建議存放敏感資訊,因為base64是對稱解密的,意味著該部分資訊可以歸類為明文資訊。
定義一個payload:
|
|
然後將其進行base64加密,得到JWT的第二部分。
|
|
1.1.3 signature
JWT的第三部分是一個簽證資訊,這個簽證資訊由三部分組成:
- header (base64後的)
- payload (base64後的)
- secret
這個部分需要base64加密後的header和base64加密後的payload使用.
連線組成的字串,然後通過header中宣告的加密方式進行加鹽secret
組合加密,然後就構成了jwt的第三部分。
|
|
將這三部分用.
連線成一個完整的字串,構成了最終的jwt:
|
|
注意:secret是儲存在伺服器端的,jwt的簽發生成也是在伺服器端的,secret就是用來進行jwt的簽發和jwt的驗證,所以,它就是你服務端的私鑰,在任何場景都不應該流露出去。一旦客戶端得知這個secret, 那就意味著客戶端是可以自我簽發jwt了。
關於簽發和核驗JWT,我們可以使用Django REST framework JWT擴充套件來完成。
文件網站:http://getblimp.github.io/django-rest-framework-jwt/
1.2 本質原理
jwt認證演算法:簽發與校驗
|
|
簽發:根據登入請求提交來的 賬號 + 密碼 + 裝置資訊 簽發 token
|
|
校驗:根據客戶端帶token的請求 反解出 user 物件
|
|
drf專案的jwt認證開發流程(重點)
|
|
1.2.1 補充base64編碼解碼
|
|
二 drf-jwt安裝和簡單使用
2.1 官網
|
|
2.2 安裝
|
|
2.3 使用:
|
|
三 實戰之使用Django auth的User表自動簽發
3.1 配置setting.py
|
|
3.2 編寫序列化類ser.py
|
|
3.3 自定義認證返回結果(setting中配置的)
|
|
3.4 基於drf-jwt的全域性認證:
|
|
3.5 全域性使用
|
|
3.6 區域性啟用禁用
|
|
3.7 多方式登入:
|
|
|
|
3.8 配置多方式登入
|
|
四 實戰之自定義User表,手動簽發
4.1 手動簽發JWT:
|
|
4.2 編寫登陸檢視類
|
|
4.3 編寫認證元件
|
|
4.4 登陸獲取token
4.5 編寫測試介面
|
|