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