• Token机制 ——JSON Web Token(JWT)的详解


    小编一直使用的是服务器的session,最近的项目,小编做成了前后端分离,遇到了一些问题:

    1. 前后端项目分属于两个域名,如果要使用session,则需要解决跨域问题
    2. 如果接口存在多个服务器的话,session小编就不建议使用了

    所以这时候,小编就想到了使用token,来验证用户的合法性。

    Token和session的区别

    1. 跨域问题:token没有跨域问题,session有跨域问题;
    2. 容易扩展:token不储存于服务器中,适用于服务器的分布式应用;
    3. CSRF:不依赖与cookie,不会受到跨站请求伪造的攻击;
    4. 性能:相对于session,少了一次sessionid的计算;

    1、传统身份验证和JWT的身份验证

    传统身份验证:

          HTTP 是一种没有状态的协议,也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求时候,还得再验证一下。 解决的方法就是,当用户请求登录的时候,如果没有问题,我们在服务端生成一条记录,这个记录里可以说明一下登录的用户是谁,然后把这条记录的 ID 号发送给客户端,客户端收到以后把这个 ID 号存储在 Cookie 里,下次这个用户再向服务端发送请求的时候,可以带着这个 Cookie ,这样服务端会验证一个这个 Cookie 里的信息,看看能不能在服务端这里找到对应的记录,如果可以,说明用户已经通过了身份验证,就把用户请求的数据返回给客户端。 上面说的就是 Session,我们需要在服务端存储为登录的用户生成的 Session ,这些 Session 可能会存储在内存,磁盘,或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

     

    安装:

    pip install djangorestframework_jwt
     

    JWT的身份验证:

    使用基于 Token 的身份验证方法,在服务端不需要存储用户的登录记录。大概的流程是这样的:


    1、客户端使用用户名跟密码请求登录
    2、服务端收到请求,去验证用户名与密码
    3、验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端
    4、客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里
    5、客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
    6、服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据

    2、JWT的token组成

    实施 Token 验证的方法挺多的,还有一些标准方法,比如 JWT,读作:jot ,表示:JSON Web Tokens 。

       JWT 标准的 Token 有三个部分:

       header(头部)

       payload(数据)

       signature(签名)

       中间用点分隔开,并且都会使用 Base64 编码,所以真正的 Token 看起来像这样:

    eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc


    头部:

    每个 JWT token 里面都有一个 header,也就是头部数据。里面包含了使用的算法,这个 JWT 是不是带签名的或者加密的。主要就是说明一下怎么处理这个 JWT token 。

    头部里包含的东西可能会根据 JWT 的类型有所变化,比如一个加密的 JWT 里面要包含使用的加密的算法。唯一在头部里面要包含的是 alg 这个属性,如果是加密的 JWT,这个属性的值就是使用的签名或者解密用的算法。如果是未加密的 JWT,这个属性的值要设置成 none

    示例:


     
     

    意思是这个 JWT 用的算法是 HS256。上面的内容得用 base64url 的形式编码一下,所以就变成这样:

     
     

    Payload:

    Payload 里面是 Token 的具体内容,这些内容里面有一些是标准字段,你也可以添加其它需要的内容。下面是标准字段:

    1. iss:Issuer,发行者

    2. sub:Subject,主题

    3. aud:Audience,观众

    4. exp:Expiration time,过期时间

    5. nbf:Not before

    6. iat:Issued at,发行时间

    7. jti:JWT ID

    比如下面这个 Payload ,用到了 iss 发行人,还有 exp 过期时间这两个标准字段。另外还有两个自定义的字段,一个是 name ,还有一个是 admin 。

     
     

    使用 base64url 编码以后就变成了这个样子:

     
     

    Signature:

    JWT 的最后一部分是 Signature ,这部分内容有三个部分,先是用 Base64 编码的 header.payload ,再用加密算法加密一下,加密的时候要放进去一个 Secret ,这个相当于是一个密码,这个密码秘密地存储在服务端。

    1. header

    2. payload

    3. secret

     

    处理完成以后看起来像这样:

     

    最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样:

     
     

    客户端收到这个 Token 以后把它存储下来,下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ,然后进行验证,通过以后就会返回给客户端想要的资源。

    ****************转摘:https://www.cnblogs.com/shao-shuai/p/10092951.html

  • 相关阅读:
    Sqoop学习笔记_Sqoop的基本使用一
    hive报错( Non-Partition column appears in the partition specification)
    【python-leetcode112-树的深度遍历】路径总和
    谷歌colab运行paddlepaddle之手写数字识别
    谷歌colab上安装百度paddlepaddle框架
    谷歌colab查看cuda的版本
    深度学习数学知识之概率论
    深度学习数学知识之线性代数
    深度学习数学知识之高等数学
    【python-leetcode113-树的深度遍历】路径总和Ⅱ
  • 原文地址:https://www.cnblogs.com/linybo/p/14640751.html
Copyright © 2020-2023  润新知