Django-REST-Framework JWT 實現SSO認證(下)

在上一篇博客中，我已經對JSON Web 認證作了簡單的解釋，這篇博客是續篇，若不瞭解，請看上一篇博客：http://www.javashuo.com/article/p-zakgrltw-nk.html

一.安裝djangorestframwork-jwt

二.用法

在你的settings.py，添加JSONWebTokenAuthentication到Django REST框架DEFAULT_AUTHENTICATION_CLASSES。

在您urls.py添加如下URL路由以啓用經過POST獲取令牌包括用戶的用戶名和密碼。

若是您使用用戶名admin和密碼password123建立了用戶，則能夠經過在終端中執行如下操做來輕鬆測試端點是否正常工做。

或者，您可使用Django REST框架支持的全部內容類型來獲取身份驗證令牌。例如：

如今，爲了訪問受保護的API，您必須包含Authorization: JWT <your_token>標題。

刷新令牌

若是JWT_ALLOW_REFRESH爲True，則能夠「刷新」 未過時的令牌以得到具備更新到期時間的全新令牌。添加這樣的URL模式：

 

將現有令牌傳遞給刷新端點，以下所示：{"token": EXISTING_TOKEN}。請注意，只有非過時的令牌纔有效。JSON響應看起來與正常獲取令牌端點相同{"token": NEW_TOKEN}。

能夠重複使用令牌刷新（令牌1 - >令牌2 - >令牌3），但此令牌鏈存儲原始令牌（使用用戶名/密碼憑據獲取）的時間，如orig_iat。您只能保持使人耳目一新的令牌JWT_REFRESH_EXPIRATION_DELTA。

一個典型的用例多是一個Web應用程序，您但願讓用戶「登陸」該站點而無需從新輸入密碼，或者在令牌過時以前被意外踢出。想象一下，他們有一個1小時的令牌，只是在他們還在作某事的最後一刻。使用移動設備，您能夠存儲用戶名/密碼以獲取新令牌，但這在瀏覽器中不是一個好主意。每次用戶加載頁面時，您均可以檢查是否存在現有的未過時令牌，若是它已接近過時，請刷新它以擴展其會話。換句話說，若是用戶正在積極使用您的網站，他們能夠保持他們的「會話」活着。

驗證令牌 

在一些微服務架構中，身份驗證由單個服務處理。其餘服務委派確認用戶已登陸此身份驗證服務的責任。這一般意味着服務將從用戶接收的JWT傳遞給身份驗證服務，並在將受保護資源返回給用戶以前等待JWT有效的確認。

使用驗證端點在此包中支持此設置。添加如下URL模式：

將令牌傳遞給驗證端點將返回200響應和令牌（若是有效）。不然，它將返回400 Bad Request以及識別令牌無效的錯誤。

其餘設置

您能夠覆蓋一些其餘設置，相似於您使用Django REST框架自己的方式。如下是全部可用的默認值。

這個包使用JSON Web Token Python實現PyJWT，並容許修改它的一些可用選項。

 參數解釋

JWT_SECRET_KEY

這是用於簽署JWT的密鑰。確保這是安全的，不共享或公開。

默認是您的項目settings.SECRET_KEY。

JWT_GET_USER_SECRET_KEY

這是JWT_SECRET_KEY的更強大版本。它是根據用戶定義的，所以若是令牌被泄露，能夠由全部者輕鬆更改。更改此值將使給定用戶的全部令牌都沒法使用。值應該是一個函數，接受用戶做爲惟一參數並返回它的密鑰。

默認是None。

JWT_PUBLIC_KEY

這是一個類型的對象cryptography.hazmat.primitives.asymmetric.rsa.RSAPublicKey。它將用於驗證傳入JWT的簽名。JWT_SECRET_KEY設置時將覆蓋。閱讀文檔以獲取更多詳細信息。請注意，JWT_ALGORITHM必須設置爲一個RS256，RS384或RS512。

默認是None。

JWT_PRIVATE_KEY

這是一個類型的對象cryptography.hazmat.primitives.asymmetric.rsa.RSAPrivateKey。它將用於簽署JWT的簽名組件。JWT_SECRET_KEY設置時將覆蓋。閱讀文檔以獲取更多詳細信息。請注意，JWT_ALGORITHM必須設置爲一個RS256，RS384或RS512。

默認是None。

JWT_ALGORITHM

可能的值是PyJWT中用於加密簽名的任何支持算法。

默認是"HS256"。

JWT_VERIFY

若是祕密是錯誤的，它會引起一個jwt.DecodeError，告訴你這樣。您仍然能夠經過設置JWT_VERIFYto來獲取有效負載False。

默認是True。

JWT_VERIFY_EXPIRATION

您能夠經過設置JWT_VERIFY_EXPIRATION爲關閉到期時間驗證False。若是沒有過時驗證，JWT將永遠存在，意味着攻擊者能夠無限期地使用泄露的令牌。

默認是True。

JWT_LEEWAY

這容許您驗證過去但不是很遠的過時時間。例如，若是您有一個JWT有效負載，其過時時間設置爲建立後30秒，但您知道有時您將在30秒後處理它，您能夠設置10秒的餘地以得到一些餘量。

默認爲0秒。

JWT_EXPIRATION_DELTA

這是Python的一個實例datetime.timedelta。將添加此項datetime.utcnow()以設置到期時間。

默認爲datetime.timedelta(seconds=300)（5分鐘）。

JWT_AUDIENCE

這是一個字符串，將根據aud令牌的字段進行檢查（若是存在）。

默認爲None（若是audJWT上存在則失敗）。

JWT_ISSUER

這是一個字符串，將根據iss令牌字段進行檢查。

默認是None（不要檢查issJWT）。

JWT_ALLOW_REFRESH

啓用令牌刷新功能。發行的令牌rest_framework_jwt.views.obtain_jwt_token將有一個orig_iat字段。默認是False

JWT_REFRESH_EXPIRATION_DELTA

限制令牌刷新，是一個datetime.timedelta實例。這是在原始令牌以後能夠刷新將來令牌的時間。

默認爲datetime.timedelta(days=7)（7天）。

JWT_PAYLOAD_HANDLER

指定自定義函數以生成令牌有效內容

JWT_PAYLOAD_GET_USER_ID_HANDLER

若是您的存儲user_id方式與默認的有效負載處理程序不一樣，請實現此功能以user_id從有效負載中獲取。注意：將不同意使用JWT_PAYLOAD_GET_USERNAME_HANDLER。

JWT_PAYLOAD_GET_USERNAME_HANDLER

若是您的存儲username方式與默認的有效負載處理程序不一樣，請實現此功能以username從有效負載中獲取。

JWT_RESPONSE_PAYLOAD_HANDLER

負責控制登陸或刷新後返回的響應數據。覆蓋以返回自定義響應，例如包括用戶的序列化表示。

默認返回JWT令牌。

如：

 

 

默認是 {'token': token}

JWT_AUTH_HEADER_PREFIX

您能夠修改須要與令牌一塊兒發送的Authorization標頭值前綴。默認值爲JWT。此決定是在PR ＃4中引入的，以容許在DRF中同時使用此程序包和OAuth2。

用於令牌和受權標頭的另外一個常見值是Bearer。

默認是JWT。

JWT_AUTH_COOKIE

若是除了Authorization標頭以外還要使用http cookie做爲令牌的有效傳輸，則能夠將其設置爲字符串。您在此處設置的字符串將用做cookie名稱，該名稱將在請求令牌時在響應標頭中設置。若是設置，令牌驗證過程也將查看此cookie。若是請求中存在標頭和cookie，則「受權」標頭優先。

默認爲None且在建立令牌時未設置cookie，在驗證令牌時也不接受。

擴展 JSONWebTokenAuthentication

如今JSONWebTokenAuthentication假設JWT將在標題中，或者若是配置了cookie（請參閱JWT_AUTH_COOKIE）。JWT規範不要求這樣作（參見：撥打服務電話）。例如，JWT可能會出如今查詢字符串中。在用戶沒法設置標題（例如HTML中的src元素）的狀況下，須要在查詢字符串中發送JWT的能力。

要實現此功能，用戶能夠編寫自定義Authentication：

建議使用BaseJSONWebTokenAuthentication一個新的基類，它沒有解析HTTP頭的邏輯。

手動建立新令牌

有時您可能但願手動生成令牌，例如在建立賬戶後當即將令牌返回給用戶。你能夠這樣作：

 

原文出處：https://www.cnblogs.com/yushenglin/p/10863311.html