Day 28 JWT認證相關

一、JWT

在用戶注冊或登錄后，我們想記錄用戶的登錄狀態，或者為用戶創建身份認證的憑證，我們不再shiyongsession認證機制，而使用Json Web Token認證機制，

Json web token (JWT), 是為了在網路應用環境間傳遞宣告而執行的一種基于JSON的開放標準（(RFC 7519).該token被設計為緊湊且安全的，特別適用于分布式站點的單點登錄（SSO）場景，JWT的宣告一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份資訊，以便于從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的宣告資訊，該token也可直接被用于認證，也可被加密，

基于token的鑒權機制

基于token的鑒權機制類似于http協議也是無狀態的，它不需要在服務端去保留用戶的認證資訊或者會話資訊，這就意味著基于token認證機制的應用不需要去考慮用戶在哪一臺服務器登錄了，這就為應用的擴展提供了便利，

流程上是這樣的：

用戶使用用戶名密碼來請求服務器
服務器進行驗證用戶的資訊
服務器通過驗證發送給用戶一個token
客戶端存盤token，并在每次請求時附送上這個token值
服務端驗證token值，并回傳資料

這個token必須要在每次請求時傳遞給服務端，它應該保存在請求頭里，另外，服務端要支持CORS(跨來源資源共享)策略，一般我們在服務端這么做就可以了Access-Control-Allow-Origin: *，

那么我們現在回到JWT的主題上，

JWT的特點

體積小，因而傳輸速度快
傳輸方式多樣，可以通過URL/POST引數/HTTP頭部等方式傳輸
嚴格的結構化，他自身在(payload中)就包含了所有與用戶相關的驗證訊息，如用戶可訪問路由、訪問有效期的資訊，服務器無需再去連接資料庫驗證資訊的有效性，并且payload支持為你的應用而定制化，
支持跨域驗證，可以應用于單點登錄，

JWT的構成

JWT就是一段字串，由三段資訊構成的，將這三段資訊文本用.鏈接一起就構成了Jwt字串，就像這樣:

ewogICd0eXAnOiAnSldUJywKICAnYWxnJzogJ0JBU0U2NCcKfQ==.ewogICJzdWIiOiAiMTIzNDU2Nzg5MCIsCiAgIm5hbWUiOiAi5bC85Y+k5ouJ5pav6LW15ZubIiwKICAiYWRtaW4iOiBmYWxzZQp9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Header

第一部分我們稱它為頭部（header），第二部分我們稱其為荷載（payload，承載的資料），第三部分是簽證（signature），

完整的頭部就像下面這樣的JSON

{
  'typ': 'JWT',
  'alg': 'BASE64'
}

然后將頭部進行base64加密（加密是對稱的，可加可解），構成了第一部分

ewogICd0eXAnOiAnSldUJywKICAnYWxnJzogJ0JBU0U2NCcKfQ==

Playload

這里是存放有效資訊的地方，有效資訊包含三個部分

標準中的注冊宣告（建議但不強制使用）
- iss：jwt簽發者
- sub：jwt所面向的用戶
- aud：接收jwt的一方
- exp：jwt的過期時間，這個過期時間必須大于簽發時間
- nbf：定義在什么時間之前，該jwt都是不可用的
- iat：jwt的簽發時間
- jti：jwt的唯一身份表示，主要用來作為一次性token，從而回避時序攻擊，
公共的宣告

這里可以添加任何的資訊，一般添加用戶的相關資訊或其他業務需要的必要資訊，但不建議添加銘感資訊，因為該部分在客戶端可解密
私有的宣告

是提供者和消費者所共同定義的宣告，一般不建議存放敏感資訊，因為base64是對稱解密的，意味著該部分資訊可以歸為明文資訊，

定義一個payload:

{
  "sub": "1234567890",
  "name": "尼古拉斯趙四",
  "admin": false
}

然后將其進行base64加密，得到jwt的第二部分

ewogICJzdWIiOiAiMTIzNDU2Nzg5MCIsCiAgIm5hbWUiOiAi5bC85Y+k5ouJ5pav6LW15ZubIiwKICAiYWRtaW4iOiBmYWxzZQp9

Signature

JWT的第三部分是一個簽證資訊，這個簽證資訊由三部分組成：

header(base64加密后的)
payload(base64加密后的)
secret（加鹽）

這個部分需要base64加密后的header和base64加密后的payload使用.連接組成的字串，然后通過header中宣告的加密方式進行加鹽secret組合加密，然后就構成了jwt的第三部分，

將這三部分用.連接成一個完整的字串，構成了最終的jwt：

ewogICd0eXAnOiAnSldUJywKICAnYWxnJzogJ0JBU0U2NCcKfQ==.ewogICJzdWIiOiAiMTIzNDU2Nzg5MCIsCiAgIm5hbWUiOiAi5bC85Y+k5ouJ5pav6LW15ZubIiwKICAiYWRtaW4iOiBmYWxzZQp9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意：secret是保存在服務器端的，jwt的簽發生成也是在服務器端的，secret就是用來進行jwt的簽發和jwt的驗證，所以，它就是你服務端的私鑰，在任何場景都不應該流露出去，一旦客戶端得知這個secret, 那就意味著客戶端是可以自我簽發jwt了，

關于簽發和核驗JWT，我們可以使用Django REST framework JWT擴展來完成，

檔案網站：http://getblimp.github.io/django-rest-framework-jwt/

二、本質原理

JWT認證演算法：簽發與校驗

jwt分三段式：頭.體.簽名（head.payload.sgin）
頭和體是可逆加密，讓服務器可以反解出user物件；簽名是不可逆加密，保證整個token的安全性的
頭體簽名三部分，都是采用json格式的字串，進行加密，可逆加密一般采用base64演算法，不可逆加密一般采用hash(md5)演算法
頭中的內容是基本資訊：公司資訊、專案組資訊、token采用的加密方式資訊

{
	"company": "公司資訊",
	...
}

體中的內容是關鍵資訊：用戶主鍵、用戶名、簽發時客戶端資訊(設備號、地址)、過期時間

{
"user_id": 1,
	...
}

簽名中的內容時安全資訊：頭的加密結果 + 體的加密結果 + 服務器不對外公開的安全碼進行md5加密

{
	"head": "頭的加密字串",
	"payload": "體的加密字串",
	"secret_key": "安全碼"
}

簽發：根據登錄請求提交來的賬號 + 密碼 + 設備資訊簽發 token

用基本資訊存盤json字典，采用base64演算法加密得到頭字串
用關鍵資訊存盤json字典，采用base64演算法加密得到體字串
用頭、體加密字串再加安全碼資訊存盤json字典，采用hash md5演算法加密得到簽名字串

賬號密碼就能根據User表得到user物件，形成的三段字串用 . 拼接成token回傳給前臺

校驗：根據客戶端帶token的請求反解出 user 物件

將token按 . 拆分為三段字串，第一段頭加密字串一般不需要做任何處理
第二段體加密字串，要反解出用戶主鍵，通過主鍵從User表中就能得到登錄用戶，過期時間和設備資訊都是安全資訊，確保token沒過期，且時同一設備來的
再用第一段 + 第二段 + 服務器安全碼不可逆md5加密，與第三段簽名字串進行碰撞校驗，通過后才能代表第二段校驗得到的user物件就是合法的登錄用戶

三、DRF專案的JWT認證開發流程（重點）

用賬號密碼訪問登錄介面，登錄介面邏輯中呼叫簽發token 演算法，得到token，回傳給客戶端，客戶端自己存到cookies中
校驗token的演算法應該寫在認證類中(在認證類中呼叫)，全域配置給認證組件，所有視圖類請求，都會進行認證校驗，所以請求帶了token，就會反解出user物件，在視圖類中用request.user就能訪問登錄的用戶

注意：登錄介面需要做認證 + 權限兩個區域禁用

四、base64編碼解碼

import base64  # 匯入模塊
import json  # 序列化

dic = {
    "key": "what a beautiful day！",
    "value": "but I still have to bring an umbrella"
}

# 序列化并指定編碼格式
byte_dic = json.dumps(dic).encode('utf-8')

# 編碼
dic_basesf = base64.b64encode(byte_dic)
print(dic_basesf)
#  # b'eyJrZXkiOiAid2hhdCBhIGJlYXV0aWZ1bCBkYXlcdWZmMDEiLCAidmFsdWUiOiAiYnV0IEkgc3RpbGwgaGF2ZSB0byBicmluZyBhbiB1bWJyZWxsYSJ9'
# 解碼
dic_str = base64.b64decode(dic_basesf)
print(dic_str)
# b'{"key": "what a beautiful day\\uff01", "value": "but I still have to bring an umbrella"}'

五、DRF-jwt安裝和簡單使用

1、安裝

pip install djangorestframework-jwt

2、使用

默認使用auth的user表中創建的用戶

# urls.py

from rest_framework_jwt.views import obtain_jwt_token

urlpatterns = [
	path('admin/', admin.site.urls),
    url(r'^login/', obtain_jwt_token),
]

postman測驗

向后端介面發送post請求，攜帶用戶名密碼，即可看到生成的token，攜帶用戶名密碼，登陸成功回傳token

3、obtain_jwt_token本質也是一個視圖類，繼承了APIView

-通過前端傳入的用戶名密碼，校驗用戶，如果校驗通過，生成token，回傳
        -如果校驗失敗，回傳錯誤資訊

4、用戶登錄才能訪問某個介面

我們先寫了一個視圖并配置好了路由

# urls.py
url(r'^text/(?P<pk>\d+)', views.TextAPI.as_view()),

# views.py
class TextAPI(GenericAPIView):
    queryset = models.Book.objects
    serializer_class = serializer.BookSerializer
    
    def get(self, request, *args, **kwargs):
        book = self.get_object()
        ser = self.get_serializer(book)
        return utils.APIResponse(data=ser.data)

這個時候未登錄沒有token也是可以訪問的，我們要想加個驗證就需要使用jwt內部的認證類，拿過來區域配置就可以了

from rest_framework_jwt.authentication import JSONWebTokenAuthentication,但是只配置他是不行的，是沒有用的，我們仍然可以訪問到具體資料，我們還需要搭配一個權限類來使用from rest_framework.permissions import IsAuthenticated

from rest_framework_jwt.authentication import JSONWebTokenAuthentication
from rest_framework.permissions import IsAuthenticated


class TextAPI(GenericAPIView):
    queryset = models.Book.objects
    serializer_class = serializer.BookSerializer
    # 只配置他是不行的，不管是否登錄，都能訪問，他需要搭配一個權限類
    authentication_classes = [JSONWebTokenAuthentication, ]
    permission_classes = [IsAuthenticated, ]
    
    def get(self, request, *args, **kwargs):
        book = self.get_object()
        ser = self.get_serializer(book)
        return utils.APIResponse(data=ser.data)

這是最簡單的使用，注意

下面圖片中Vaule一定要帶 jwt + 一個空格 +token

5、如果用戶攜帶了token，并且配置了`JSONWebTokenAuthentication`，從request.user就能拿到當前登錄用戶，如果沒有攜帶，當前登錄用戶就是匿名用戶

注意：如果不加DRF內置的IsAuthenticated那他登錄也可以訪問，沒登錄也可以訪問

6、obtain_jwt_token原始碼分析

六、控制登錄介面回傳的資料格式

1 控制登錄介面回傳的資料格式如下
    {
    code:100
    msg:登錄成功
    token：asdfasfd
    username：egon
    }
    
2 寫一個函式
	from homework.serializer import UserReadOnlyModelSerializer
    def jwt_response_payload_handler(token, user=None, request=None):
        return {'code': 100, 
                'msg': '登錄成功',
                'token': token,
                'user': UserReadOnlyModelSerializer(instance=user).data
                }
3 在setting.py中配置
	import datetime
    JWT_AUTH = {
        'JWT_RESPONSE_PAYLOAD_HANDLER': 'homework.utils.jwt_response_payload_handler',
    }

七、自定義基于jwt的認證類

1 自己實作基于jwt的認證類，通過認證，才能繼續訪問，通不過認證就回傳錯誤
2 代碼如下
	    
    class JwtAuthentication(BaseJSONWebTokenAuthentication):
        def authenticate(self, request):
            # 認證邏輯()
            # token資訊可以放在請求頭中,請求地址中
            # key值可以隨意叫
            # token=request.GET.get('token')
            token=request.META.get('HTTP_Authorization'.upper())
            # 校驗token是否合法
            try:
                payload = jwt_decode_handler(token)
            except jwt.ExpiredSignature:
                raise AuthenticationFailed('過期了')
            except jwt.DecodeError:
                raise AuthenticationFailed('解碼錯誤')
            except jwt.InvalidTokenError:
                raise AuthenticationFailed('不合法的token')
            user=self.authenticate_credentials(payload)
            return (user, token)
 3 在視圖類中配置
	authentication_classes = [JwtAuthentication, ]

Another

集群：物理形態

同一個業務，部署在多個服務器上

分布式：作業方式

一個業務分拆多個子業務，部署在不同的服務器上

小飯店原來只有一個廚師，切菜洗菜備料炒菜全干，后來客人多了，廚房一個廚師忙不過來，又請了個廚師，兩個廚師都能炒一樣的菜，這兩個廚師的關系是集群，為了讓廚師專心炒菜，把菜做到極致，又請了個配菜師負責切菜，備菜，備料，廚師和配菜師的關系是分布式，一個配菜師也忙不過來了，又請了個配菜師，兩個配菜師關系是集群

反向代理

是指以代理服務器來接受internet上的連接請求，然后將請求轉發給內部網路上的服務器，并將從服務器上得到的結果回傳給internet上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器，

正向代理

它隱藏了真實的請求客戶端， 服務端不知道真實的客戶端是誰，客戶端清求的服務都被代理服務器代替來請求，

對稱加密

指的就是加、解密使用的同是一串密鑰，所以被稱做對稱加密，對稱加密只有一個密鑰作為私鑰，常見的對稱加密演算法：DES，AES等，

優缺點

對稱加密相比非對稱加密演算法來說，加解密的效率要高得多、加密速度快，但是缺陷在于對于密鑰的管理和分發上比較困難，不是非常安全，密鑰管理負擔很重，

非對稱加密

指的是加、解密使用不同的密鑰，一把作為公開的公鑰，另一把作為私鑰，公鑰加密的資訊，只有私鑰才能解密，反之，私鑰加密的資訊，只有公鑰才能解密，

優缺點

安全性更高，公鑰是公開的，密鑰是自己保存的，不需要將私鑰給別人，缺點：加密和解密花費時間長、速度慢，只適合對少量資料進行加密，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/224739.html

標籤：其他

上一篇：睿智的目標檢測44——Keras 搭建自己的Centernet目標檢測平臺

下一篇：校園網自動登錄，斷線重連

Day 28 JWT認證相關

Day 28 JWT認證相關

一、JWT

基于token的鑒權機制

JWT的特點

JWT的構成

Header

Playload

定義一個payload:

Signature

二、 本質原理

JWT認證演算法：簽發與校驗

簽發：根據登錄請求提交來的 賬號 + 密碼 + 設備資訊 簽發 token

校驗：根據客戶端帶token的請求 反解出 user 物件

三、DRF專案的JWT認證開發流程（重點）

四、base64編碼解碼

五、DRF-jwt安裝和簡單使用

1、安裝

2、使用

3、obtain_jwt_token本質也是一個視圖類，繼承了APIView

4、用戶登錄才能訪問某個介面

5、如果用戶攜帶了token，并且配置了JSONWebTokenAuthentication，從request.user就能拿到當前登錄用戶，如果沒有攜帶，當前登錄用戶就是匿名用戶

6、obtain_jwt_token原始碼分析

六、控制登錄介面回傳的資料格式

七、自定義基于jwt的認證類

Another

集群：物理形態

分布式：作業方式

反向代理

正向代理

對稱加密

優缺點

非對稱加密

優缺點

二、本質原理

簽發：根據登錄請求提交來的賬號 + 密碼 + 設備資訊簽發 token

校驗：根據客戶端帶token的請求反解出 user 物件

5、如果用戶攜帶了token，并且配置了`JSONWebTokenAuthentication`，從request.user就能拿到當前登錄用戶，如果沒有攜帶，當前登錄用戶就是匿名用戶