官網(wǎng)：http://jpadilla.github.io/django-rest-framework-jwt/
Django一般采用三種驗證方式
SessionAuthentication, BasicAuthentication敞曹，Token
SessionAuthentication:一般采用這個驗證的話临梗，未登錄是看不到內(nèi)容的租冠，B/S（適用于瀏覽器訪問）
BasicAuthentication：彈窗式登錄站玄，B/S
Token：獲得認證的Token后才能看到內(nèi)容,C/S（客戶端/服務(wù)器）,前后端分離, DRF自帶，沒有過期時間（服務(wù)端），JWT使用Base64 編碼后者春，再使用相應(yīng)的非對稱加密算法進行簽名/加密

前后端分離之JWT用戶認證（概念理解）

在前后端分離開發(fā)時為什么需要用戶認證呢膘侮？原因是由于HTTP協(xié)定是不儲存狀態(tài)的(stateless)，這意味著當(dāng)我們透過帳號密碼驗證一個使用者時玩徊，當(dāng)下一個request請求時它就把剛剛的資料忘了租悄。于是我們的程序就不知道誰是誰，就要再驗證一次恩袱。所以為了保證系統(tǒng)安全泣棋，我們就需要驗證用戶否處于登錄狀態(tài)。

傳統(tǒng)方式
前后端分離通過Restful API進行數(shù)據(jù)交互時畔塔，如何驗證用戶的登錄信息及權(quán)限潭辈。在原來的項目中，使用的是最傳統(tǒng)也是最簡單的方式俩檬，前端登錄萎胰，后端根據(jù)用戶信息生成一個token，并保存這個 token 和對應(yīng)的用戶id到數(shù)據(jù)庫或Session中棚辽，接著把 token 傳給用戶技竟，存入瀏覽器 cookie，之后瀏覽器請求帶上這個cookie屈藐，后端根據(jù)這個cookie值來查詢用戶榔组，驗證是否過期。

但這樣做問題就很多联逻，如果我們的頁面出現(xiàn)了 XSS 漏洞搓扯，由于 cookie 可以被 JavaScript 讀取，XSS 漏洞會導(dǎo)致用戶 token 泄露包归，而作為后端識別用戶的標(biāo)識锨推，cookie 的泄露意味著用戶信息不再安全。盡管我們通過轉(zhuǎn)義輸出內(nèi)容公壤，使用 CDN 等可以盡量避免 XSS 注入换可，但誰也不能保證在大型的項目中不會出現(xiàn)這個問題。

在設(shè)置 cookie 的時候厦幅，其實你還可以設(shè)置 httpOnly 以及 secure 項沾鳄。設(shè)置 httpOnly 后 cookie 將不能被 JS 讀取，瀏覽器會自動的把它加在請求的 header 當(dāng)中确憨，設(shè)置 secure 的話译荞，cookie 就只允許通過 HTTPS 傳輸瓤的。secure 選項可以過濾掉一些使用 HTTP 協(xié)議的 XSS 注入，但并不能完全阻止吞歼。

httpOnly 選項使得 JS 不能讀取到 cookie圈膏，那么 XSS 注入的問題也基本不用擔(dān)心了。但設(shè)置 httpOnly 就帶來了另一個問題浆熔，就是很容易的被 XSRF本辐，即跨站請求偽造。當(dāng)你瀏覽器開著這個頁面的時候医增，另一個頁面可以很容易的跨站請求這個頁面的內(nèi)容。因為 cookie 默認被發(fā)了出去老虫。

另外叶骨，如果將驗證信息保存在數(shù)據(jù)庫中，后端每次都需要根據(jù)token查出用戶id祈匙，這就增加了數(shù)據(jù)庫的查詢和存儲開銷忽刽。若把驗證信息保存在session中，有加大了服務(wù)器端的存儲壓力夺欲。那我們可不可以不要服務(wù)器去查詢呢跪帝？如果我們生成token遵循一定的規(guī)律，比如我們使用對稱加密算法來加密用戶id形成token些阅，那么服務(wù)端以后其實只要解密該token就可以知道用戶的id是什么了伞剑。不過呢，我只是舉個例子而已市埋，要是真這么做黎泣，只要你的對稱加密算法泄露了，其他人可以通過這種加密方式進行偽造token缤谎，那么所有用戶信息都不再安全了抒倚。恩，那用非對稱加密算法來做呢坷澡，其實現(xiàn)在有個規(guī)范就是這樣做的托呕，就是我們接下來要介紹的 JWT。

Json Web Token（JWT）

JWT 是一個開放標(biāo)準(zhǔn)(RFC 7519)频敛，它定義了一種用于簡潔项郊，自包含的用于通信雙方之間以 JSON 對象的形式安全傳遞信息的方法。JWT 可以使用 HMAC 算法或者是 RSA 的公鑰密鑰對進行簽名姻政。它具備兩個特點：

簡潔(Compact)
可以通過URL, POST 參數(shù)或者在 HTTP header 發(fā)送呆抑，因為數(shù)據(jù)量小，傳輸速度快

自包含(Self-contained)
負載中包含了所有用戶所需要的信息汁展，避免了多次查詢數(shù)據(jù)庫

JWT 組成

image.png

Header 頭部

頭部包含了兩部分鹊碍，token 類型和采用的加密算法

{
"alg": "HS256",
"type": "JWT"
}
它會使用 Base64 編碼組成 JWT 結(jié)構(gòu)的第一部分,如果你使用Node.js厌殉，可以用Node.js的包base64url來得到這個字符串。

Base64是一種編碼侈咕，也就是說公罕，它是可以被翻譯回原來的樣子來的。它并不是一種加密過程耀销。

Payload 負載

這部分就是我們存放信息的地方了楼眷，你可以把用戶 ID 等信息放在這里，JWT 規(guī)范里面對這部分有進行了比較詳細的介紹熊尉，常用的由 iss（簽發(fā)者）罐柳，exp（過期時間），sub（面向的用戶）狰住，aud（接收方）张吉，iat（簽發(fā)時間）。

{
"iss": "qfedu.com",
"iat": 1441593502,
"exp": 1441594722,
"aud": "www.example.com",
"sub": "sharkyun@163.com"
}
同樣的催植，它會使用 Base64 編碼組成 JWT 結(jié)構(gòu)的第二部分

Signature 簽名

前面兩部分都是使用 Base64 進行編碼的肮蛹，即前端可以解開知道里面的信息。Signature 需要使用編碼后的 header 和 payload 以及我們提供的一個密鑰创南，然后使用 header 中指定的簽名算法（HS256）進行簽名伦忠。簽名的作用是保證 JWT 沒有被篡改過。

三個部分通過.連接在一起就是我們的 JWT 了稿辙，它可能長這個樣子昆码，長度貌似和你的加密算法和私鑰有關(guān)系。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s
其實到這一步可能就有人會想了邓深，HTTP 請求總會帶上 token未桥，這樣這個 token 傳來傳去占用不必要的帶寬啊。如果你這么想了芥备，那你可以去了解下 HTTP2冬耿，HTTP2 對頭部進行了壓縮，相信也解決了這個問題萌壳。

簽名的目的
最后一步簽名的過程亦镶，實際上是對頭部以及負載內(nèi)容進行簽名，防止內(nèi)容被竄改袱瓮。如果有人對頭部以及負載的內(nèi)容解碼之后進行修改缤骨，再進行編碼，最后加上之前的簽名組合形成新的JWT的話尺借，那么服務(wù)器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的绊起。如果要對新的頭部和負載進行簽名，在不知道服務(wù)器加密時用的密鑰的話燎斩，得出來的簽名也是不一樣的虱歪。

信息暴露
在這里大家一定會問一個問題：Base64是一種編碼蜂绎，是可逆的，那么我的信息不就被暴露了嗎笋鄙？

是的师枣。所以，在JWT中萧落，不應(yīng)該在負載里面加入任何敏感的數(shù)據(jù)践美。在上面的例子中，我們傳輸?shù)氖怯脩舻腢ser ID找岖。這個值實際上不是什么敏感內(nèi)容陨倡，一般情況下被知道也是安全的。但是像密碼這樣的內(nèi)容就不能被放在JWT中了许布。如果將用戶的密碼放在了JWT中玫膀，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。

因此JWT適合用于向Web應(yīng)用傳遞一些非敏感信息爹脾。JWT還經(jīng)常用于設(shè)計用戶認證和授權(quán)系統(tǒng)，甚至實現(xiàn)Web應(yīng)用的單點登錄箕昭。

JWT 使用

image.png

image.png

首先灵妨，前端通過Web表單將自己的用戶名和密碼發(fā)送到后端的接口。這一過程一般是一個HTTP POST請求落竹。建議的方式是通過SSL加密的傳輸（https協(xié)議）泌霍，從而避免敏感信息被嗅探。
后端核對用戶名和密碼成功后述召，將用戶的id等其他信息作為JWT Payload（負載）朱转，將其與頭部分別進行Base64編碼拼接后簽名，形成一個JWT积暖。形成的JWT就是一個形同lll.zzz.xxx的字符串藤为。
后端將JWT字符串作為登錄成功的返回結(jié)果返回給前端。前端可以將返回的結(jié)果保存在localStorage或sessionStorage上夺刑，退出登錄時前端刪除保存的JWT即可缅疟。
前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
后端檢查是否存在遍愿，如存在驗證JWT的有效性存淫。例如，檢查簽名是否正確沼填；檢查Token是否過期桅咆；檢查Token的接收方是否是自己（可選）。
驗證通過后后端使用JWT中包含的用戶信息進行其他邏輯操作坞笙，返回相應(yīng)結(jié)果岩饼。
和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在于Session是存儲在服務(wù)器端的荚虚，所以需要占用大量服務(wù)器內(nèi)存，對于較大型應(yīng)用而言可能還要保存許多的狀態(tài)忌愚。一般而言曲管，大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫和一系列緩存機制來實現(xiàn)Session的存儲。

而JWT方式將用戶狀態(tài)分散到了客戶端中硕糊，可以明顯減輕服務(wù)端的內(nèi)存壓力院水。除了用戶id之外，還可以存儲其他的和用戶相關(guān)的信息简十，例如該用戶是否是管理員檬某、用戶所在的分組等。雖說JWT方式讓服務(wù)器有一些計算壓力（例如加密螟蝙、編碼和解碼）恢恼，但是這些壓力相比磁盤存儲而言可能就不算什么了。具體是否采用胰默，需要在不同場景下用數(shù)據(jù)說話场斑。

單點登錄
Session方式來存儲用戶id，一開始用戶的Session只會存儲在一臺服務(wù)器上牵署。對于有多個子域名的站點漏隐，每個子域名至少會對應(yīng)一臺不同的服務(wù)器，例如：www.taobao.com奴迅，nv.taobao.com青责，nz.taobao.com，login.taobao.com取具。所以如果要實現(xiàn)在login.taobao.com登錄后脖隶，在其他的子域名下依然可以取到Session，這要求我們在多臺服務(wù)器上同步Session暇检。使用JWT的方式則沒有這個問題的存在产阱，因為用戶的狀態(tài)已經(jīng)被傳送到了客戶端。

總結(jié)
JWT的主要作用在于（一）可附帶用戶信息占哟，后端直接通過JWT獲取相關(guān)信息心墅。（二）使用本地保存，通過HTTP Header中的Authorization位提交驗證榨乎。但其實關(guān)于JWT存放到哪里一直有很多討論怎燥，有人說存放到本地存儲，有人說存 cookie蜜暑。

關(guān)于使用

1. 安裝
   注意：切換到自己項目的 Python 環(huán)境中進行安裝

$ pip3 install djangorestframework-jwt

2. 使用
   2.1 全局設(shè)置使用
   在 settings.py 中铐姚，添加JSONWebTokenAuthentication 到 Django REST 框架的DEFAULT_AUTHENTICATION_CLASSES。

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    ),
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_jwt.authentication.JSONWebTokenAuthentication',
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.BasicAuthentication',
    ),
}

在 urls.py 中添加以下URL 路由, 這樣可以啟用通過 POST 請求來獲得用戶令牌的功能，發(fā)送 POST 請求時需要提供用戶的用戶名和密碼隐绵。

2.2 視圖設(shè)置使用

from rest_framework_jwt.authentication import JSONWebTokenAuthentication
class UsersSeriaView(APIView):
    authentication_classes = [JSONWebTokenAuthentication]
    permission_classes = [IsAuthenticated]

配置

from rest_framework_jwt.views import obtain_jwt_token
#...

urlpatterns = [
    '',
    # ...

    path(r'api-token-auth/', obtain_jwt_token),
]

設(shè)置 Tocken 有效時間和認證 token 信息的前綴
在 settings.py 文件中設(shè)置

import datetime
JWT_AUTH = {
    'JWT_REFRESH_EXPIRATION_DELTA': datetime.timedelta(days=7),

    'JWT_AUTH_HEADER_PREFIX': 'JWT',
}

postman 工具

獲取 token,每次的token只能用一次之众，下一次需要重新獲取

image.png

獲取 token

image.png