zoukankan      html  css  js  c++  java
  • 漫谈JWT

    一、JWT简介【对于了解JWT的童鞋,可以直接跳到最后】

    咱们就不弄那些乱七八糟的概念,就简单点说一下JWT是什么、有什么和能干什么

    1、 JWT概念和作用

    JWT全称为json web token,说白了是什么呢? 就仅仅只是一个字符串而已,例如:

    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0.OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ 这样。

    O(∩_∩)O 是不是特别长,特别丑?没关系,现在给大家解释一下这个东东到底是什么

    2、JWT组成【对于JWT有基本了解的人可以忽略这一部分】

    JWT包含了三个主要部分: Header.Payload.Signature,以" . "来进行分割,以上式举例:
    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
    eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0.
    OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ

    注意尾巴上的两个点哦。

    2.1 Header作用

    Header部分主要存储关于签名算法的信息,通常不包含两个部分:token类型和采用的加密算法,大致源内容如下:
    { "alg": "HS256", "typ": "JWT"} ,然后使用Base64Url编码组成了Header部分,结果大致如:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。

    2.2 Payload作用

    Payload翻译过来就是负载嘛,就是装东西嘛对不对,所以这一部分其实是用来存储一些信息的,至于是什么信息呢,重点来了 ----> 无所谓,惊不惊喜,意不意外?

    其实Payload是一个比较重要的部分,这个东西其实就是一个数据实体,俗称Claim,JWT并不强制使用,它默认这一部分数据为业务数据,是系统业务需要的数据,可有可无,可多可少。一般在不特殊修改的情况下,主要包含几个部分: iss(签发者),exp(过期时间戳), sub(面向的用户), aud(接收方), iat(签发时间),大致的源样式是这样:
    { "sub": "1234567890", "name": "John Doe", "admin": true},经过Base64Url 编码以后,会变成JWT的第二部分字符串:eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0。

    2.3 Signature作用

    创建签名需要使用编码后的header和payload以及一个秘钥,组成的公式:编码后的header、编码后的payload、一个secret进行加密HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

    以上就是JWT的几个主要组成部分。

    3、JWT的主要作用

    JWT最开始的初衷是为了实现授权和身份认证作用的,可以实现无状态、分布式的Web应用授权,大致实现的流程如下:

    图片描述

    图中内容可见,JWT的使用流程大致有几步:

    1、客户端需要携带用户名/密码等可证明身份的内容去授权服务器获取JWT信息;

    2、每次服务都携带该Token内容与Web服务器进行交互,由业务服务器来来验证Token是否是授权系统发放的有效Token,来验证当前业务是否请求是否合法。

    注意:这里很多刚接触JWT的童鞋经常会问一个问题,是不是每次请求都申请一次Token,这里需要注意,如果不是对于安全性要求非常高的情况,不建议每次请求都申请,因为会增加业务耗时,大部分时候我个人喜欢在登陆时申请,然后使用JWT的过期时间或其他手段来保障JWT的有效性

    后来随着JWT使用的场景的成熟,逐渐引申的意义也可以抵御跨站请求伪造攻击【就不解释这是什么了,可以百度一下】和签名验签的流程。

    以下是福利环节,也是重点答疑环节。

    a)如何保证JWT的安全呢?

    注意,这里经常会有一个误区,JWT本身和安全没关系,它就仅仅只是一个字符串,使用它来做安全远不如类似于RSA2这样的非对称加密的形式来的实在,由于客户端的程序对用户几乎完全透明,验签的过程对于他们来讲也是透明的,所以安全性肯定不会靠这个来实现,如果实在怕JWT的被盗取,可以考虑在Payload部分加入一些客户端独有的非敏感信息,用于在服务端来进行核验,比如使用MAC-Message Authentication Code、或者公钥之类的等等; 或者干脆就把生效时间设置的短一些,也可以减少暴漏的风险。

    b)要不要将用户信息存入Payload呢

    其实是一个道理,由于JWT本身没有安全性可言,所以存储用户信息,尤其是敏感数据是一件很可怕的事情,建议不要存放这一类信息;而且将太多的信息存入Payload以后,就增加了网络传输以及签名和验签的复杂度,也会造成时间的浪费;

    c)如果想上传视频,如何使用JWT进行签名呢

    这件事要分两头说,JWT签名对我个人而言,并不是所有数据都要签名,因为会增加业务耗时和复杂度,所以我一般都是对一些敏感数据才会进行签名。基于以上基点,不难分析出这个问题的答案:
    1、如果视频并不算敏感数据,那么自然就不存在签名问题
    2、如果确实认为视频是敏感数据,可以通过nodejs之类的东东获取到上传文件的对象,然后进行操作,当然,这是一个非常复杂的工作,要有心理准备哦。
    3、这个问题其实仅仅只是一个例子,所有类似的问题处理方法差不多,只要意识到什么数据应该签名,什么数据可以不签名,其他都是一些技术细节,这里就不讨论了。



  • 相关阅读:
    艾伟:[WCF中的Binding模型]之六(完结篇):从绑定元素认识系统预定义绑定 狼人:
    艾伟:.NET框架4.0中都有些什么? 狼人:
    艾伟:WM有约(三):下一次是什么时候? 狼人:
    艾伟:为什么微软要推 ADO.NET Data Services Framework 狼人:
    艾伟:WM有约(二):配置信息 狼人:
    艾伟:F4何去何从 大视野观察Framework 4.0 狼人:
    艾伟:[WCF的Binding模型]之三:信道监听器(Channel Listener) 狼人:
    艾伟:.NET : 如何保护内存中的敏感数据? 狼人:
    艾伟:Silverlight 2.0 之旋转木马 狼人:
    艾伟:.NET和J2EE该相互学习什么 狼人:
  • 原文地址:https://www.cnblogs.com/kkdn/p/9328266.html
Copyright © 2011-2022 走看看