Django: DRF基于Token的身份验证 vs JSON Web Token

65

我正在构建一个真实世界的应用程序,用户主要从Android、iOS设备和桌面访问该应用程序。

经过初步研究,我发现令牌(Token)认证机制比基于会话的认证机制更适合客户端-服务器模型,而且更加优雅。

在Django中,我发现了两种流行的方法:

  1. http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
  2. http://getblimp.github.io/django-rest-framework-jwt/

从我的理解来看,选项2]是选项1]的扩展,只不过令牌以JSON(序列化)形式呈现。我想了解选项1]和2]之间的其他区别,以及选择其中任何一个的优缺点。


1
我有一个类似的设置。我的应用程序客户端使用令牌身份验证,但我的Web客户端使用会话身份验证。不确定JWT将提供什么优势? - Rajesh Kaushik
4
就我所知,django-rest-framework-simplejwt 似乎在维护中,而 django-rest-framework-jwt 则不是。 - phoenix
2个回答

123

它们都执行类似的任务,但存在一些差异。

令牌

DRF内置的令牌认证

  1. 一个令牌适用于所有会话
  2. 令牌没有时间戳

DRF JWT令牌认证

  1. 每个会话有一个令牌
  2. 每个令牌有过期时间戳

数据库访问

DRF内置的令牌认证

  1. 访问数据库以获取与令牌相关联的用户
  2. 验证用户状态
  3. 验证用户身份

DRF JWT令牌认证

  1. 解码令牌(获得有效载荷)
  2. 验证令牌时间戳(过期)
  3. 访问数据库以获取与有效载荷中的ID相关联的用户
  4. 验证用户状态
  5. 验证用户身份

优点

DRF内置的令牌认证

  1. 允许通过在数据库中替换令牌(例如更改密码)来强制注销

DRF JWT令牌认证

  1. 带有过期时间的令牌
  2. 除非令牌有效,否则不会访问数据库

缺点

DRF内置的令牌认证

  1. 在所有请求上访问数据库
  2. 所有会话只有一个令牌

DRF JWT令牌认证

  1. 无法在不跟踪数据库中的令牌的情况下召回令牌
  2. 一旦颁发了令牌,任何持有该令牌的人都可以发出请求
  3. 规范存在多种解释,没有统一的关于如何进行刷新的共识

1
抱歉,我不明白您的回答。您能否澄清一下?您是指使用选项1时需要在会话中记住用户,而对于选项2,您只需检查请求URL中的用户名,因此选项2不需要会话? - Sander Vanden Hautte
@SanderVandenHautte 我在我的回答中添加了更多细节。希望有所帮助。 - Avid Coder
谢谢!那很有帮助。 - Sander Vanden Hautte
@un33k,你能详细说明一下吗? 规格存在不同的解释,对于如何进行刷新没有共识。 - sphoenix
3
@sphoenix,这是一个复杂的话题,stackoverflow不适合进行详细分析。请将上述内容作为正反两方面的参考,然后结合你的设计需求和包使用情况,找出最适合你的方案。请注意,认证没有万全之策,任何选择都会有副作用。任务是最小化满足你需求的副作用。如果我要推荐的话,建议使用签名 Http cookies 进行身份验证,使用 JWT 进行授权。Cookie 有效期为2周,JWT 每15分钟更新一次。 - Avid Coder

-4
Django提供了两种常用的身份验证方法:Token Authentication和JSON Web Tokens(JWT)Authentication。每种方法都有其自身的优点和使用场景,选择哪种方法取决于您的应用程序需求。以下是两种方法的比较:
令牌身份验证: - 无状态:通常使用数据库表来存储用户令牌来实现令牌身份验证。每个令牌与特定用户关联,并具有过期日期。它不需要服务器端存储会话数据。 - 可扩展性:由于令牌身份验证是无状态的,因此可以更容易地进行水平扩展。您可以添加更多服务器来处理增加的流量,而无需担心会话管理。 - 简单:在Django中相对简单实现令牌身份验证。Django通过“Token”模型提供了内置支持。 - 信息有限:令牌通常只包含有关用户的基本信息,例如用户ID。如果您需要在令牌中包含其他用户数据,则需要为每个请求查询数据库。 - 缺乏标准:与JWT不同,令牌身份验证没有标准化的格式,因此您可能需要手动处理令牌的创建和验证。
JWT(JSON Web Tokens)身份验证: - 无状态:与令牌身份验证类似,JWT也是无状态的。它不需要服务器端存储会话数据。 - 自包含:JWT是自包含的,可以在令牌本身中存储附加的用户数据(声明)。这意味着一旦解码JWT,您就可以访问用户信息,而无需进行额外的数据库查询。 - 标准化:JWT是一个开放标准(RFC 7519),具有明确定义的结构和适用于多种编程语言的库,因此在互操作性方面是一个很好的选择。 - 安全性:JWT可以进行签名并可选择进行加密,提供更高级别的安全性。它们对篡改具有抵抗力,因为在验证过程中可以检测到令牌的任何修改。 - 复杂性:实现JWT可能比令牌身份验证更复杂,特别是在密钥管理和令牌验证方面。
总结一下,令牌认证是一个更简单的选择,适用于基本用例,您不需要在令牌中存储额外的用户数据,也不需要标准化的格式。另一方面,JWT认证是一个更强大和灵活的选项,适用于需要自包含令牌、标准化格式和增强安全功能的应用程序。
您在这两种方法之间的选择应该取决于您的应用程序的具体要求以及您对相关技术的熟悉程度。

3
本站不接受由人工智能生成的答案。请参阅https://stackoverflow.com/help/gpt-policy。 - undefined

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接