ibcadmin 发表于 2019-9-17 11:33:25

认证方案之初步认识JWT

<p>媒介:</p>
<p><div align="center"></div></p>
<p>现在越来越多的项目或多或少会用到JWT,为什么会出现使用JWT如许的场景的呢?</p>
<p>假设现在有一个APP,配景是分布式系统。APP的首页模块摆设在上海机房的服务器上,子页面模块摆设在深圳机房的服务器上。此时你从首页登录了该APP,然后跳转到子页面模块。session在两个机房之间不能同步,用户是否须要重新登录?</p>
<p>传统的方式(cookie+session)须要重新登录,用户体验不好。session共享(在多台物理机之间传输和复制session)方式对网络IO的压力大,耽误太长,用户体验也不好。</p>
<p>说到这大家大概会想到,用服务器的session_id存储到cookies中也能做到,为什么非要用token呢?网上有很多文章来比力token和session的优缺点,其实,开辟web应用的话用哪种都行。但如果是开辟api接口,前后端分离,最好使用token,为什么这么说呢,由于session+cookies是基于web的。但是针对 api接口,大概会思量到移动端,app是没有cookies和session的。</p>
<p><strong>Session方式存储用户信息的最大问题在于要占用大量服务器内存,增长服务器的开销。</strong></p>
<p><strong>而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。Session的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端</strong></p>
<p><div align="center"></div></p>
<p>原理:</p>
<p>JSON Web Token(缩写 JWT)</p>
<p><div align="center"></div></p>
<p>    JWT 的原理是,服务器认证以后,天生一个 JSON 对象,发回给用户,以后,用户与服务端通信的时间,都要发回这个 JSON 对象。</p>
<p>服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据,服务器在天生这个对象的时间,会加上签名。</p>
<p>服务器就不生存任何 session 数据了,也就是说,服务器酿成无状态了,从而比力轻易实现扩展。</p>
<p>组合:</p>
<p> JWT 的三个部分依次是:<strong>Header</strong>(头部)、<strong>Payload</strong>(负载)、<strong>Signature</strong>(签名)</p>
<p>写成一行,就是下面的样子。</p>
<strong><code >Header.Payload.Signature</code></strong>
<p><div align="center"></div></p>
<p> 一、Header</p>
<p>header典范的由两部分构成:token的范例(“JWT”)和算法名称(比如:HMAC SHA256或者RSA等等)</p>

      {
          "alg": "HS256", //alg属性表示签名的算法(algorithm),默认是 HMAC SHA256(写成 HS256)
          "typ": "JWT"   //typ属性表示这个令牌(token)的范例(type)
      }

<p>然后用Base64对这个JSON编码就得到JWT的第一部分</p>
<p>二、Payload</p>
<p>JWT的第二部分是payload,它包罗声明(要求)。声明是关于实体(通常是用户)和其他数据的声明</p>
<p>JWT 规定了7个官方字段</p>
<ul>
<li>iss (issuer):签发人</li>
<li>exp (expiration time):逾期时间</li>
<li>sub (subject):主题</li>
<li>aud (audience):受众</li>
<li>nbf (Not Before):生效时间</li>
<li>iat (Issued At):签发时间</li>
<li>jti (JWT ID):编号</li>
</ul>
<p>除了官方字段,你还可以在这个部分定义私有字段,下面就是一个例子</p>

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

注意,不要在JWT的payload或header中放置敏感信息,除非它们是加密的
<p>三、Signature</p>
<p>Signature 部分是对前两部分的签名,防止数据篡改。签名是用于验证消息在转达过程中有没有被更改,而且,对于使用私钥签名的token,它还可以验证JWT的发送方是否为它所称的发送方。</p>
<p>为了得到签名部分,你必须有编码过的header、编码过的payload、一个秘钥,签名算法是header中指定的谁人,然对它们签名即可。按照下面的公式产生签名。</p>
<p>HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)</p>
<p>算出签名以后,把 Header、Payload、Signature 三个部分拼成一个字符串,每个部分之间用"点"(<code>.</code>)分隔,就可以返回给用户。</p>
<p> <div align="center"></div></p>
<p>开始:</p>
<p> 一、客户端收到服务器返回的 JWT,可以储存在 Cookie 内里,也可以储存在 localStorage。</p>
<p>以后,客户端每次与服务器通信,都要带上这个 JWT。你可以把它放在 Cookie 内里自动发送,但是如许不能跨域,以是更好的做法是放在 HTTP 哀求的头信息<code>Authorization</code>字段内里。</p>

Authorization: Bearer <token>

<p>二、JWT 就放在 POST 哀求的数据体内里,那么跨源资源共享(CORS)将不会成为问题,由于它不使用cookie</p>
<p><div align="center"></div></p>
<p>1.应用(或者客户端)想授权服务器哀求授权。例如,如果用授权码流程的话,就是/oauth/authorize</p>
<p>2.当授权被许可以后,授权服务器返回一个access token给应用</p>
<p>3.应用使用access token访问受掩护的资源(比如:API)</p>
<p>特点:</p>
<p>1.JWT 默认是不加密,但也是可以加密的。天生原始 Token 以后,可以用密钥再加密一次。</p>
<p>2.JWT 不加密的情况下,不能将机密数据写入 JWT。</p>
<p>3.JWT 的最大缺点是,由于服务器不生存 session 状态,因此无法在使用过程中废止某个 token,或者更改 token 的权限。也就是说,一旦 JWT 签发了,在到期之前就会始终有效,除非服务器摆设额外的逻辑。</p>
<p>4.JWT 自己包罗了认证信息,一旦泄漏,任何人都可以得到该令牌的全部权限。为了减少盗用,JWT 的有效期应该设置得比力短。对于一些比力重要的权限,使用时应该再次对用户进行认证。</p>
<p>注意:</p>
<p>JWT 是 JSON 格式的被加密了的字符串</p>
<p>JWT 的核心是密钥,就是 JSON 数据。这是你关心的,并希望安全转达出去的数据。JWT 怎样做到这一点,并使你信任它,就是加密签名。</p>
<p><div align="center"></div></p>
<p> </p>
<p>被篡改之后</p>
<p> </p>
<p> <div align="center"></div></p>
<p>总结:</p>
<p>参考官方文档:JSON Web Tokens</p>
<p> </p><br><br/><br/><br/><br/><br/>来源:<a href="https://www.cnblogs.com/i3yuan/archive/2019/09/14/11519431.html" target="_blank">https://www.cnblogs.com/i3yuan/archive/2019/09/14/11519431.html</a>
页: [1]
查看完整版本: 认证方案之初步认识JWT