基于token的鉴权机制 — JWT介绍

  前言:在实际开发项目中,由于Http是一种无状态的协议,我们想要记录用户的登录状态,或者为用户创建身份认证的凭证,可以使用Session认证机制或者JWT认证机制。

什么是JWT?

  Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

JWT与Session的区别

Session  

  传统的session认证:我们知道,http协议本身是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,我们并不能知道是哪个用户发出的请求,所以为了让我们的应用能识别是哪个用户发出的请求,我们只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

但是这种基于session的认证使应用本身很难得到扩展,随着不同客户端用户的增加,独立的服务器已无法承载更多的用户,而这时候基于session认证应用的问题就会暴露出来。

  基于session认证所显露的问题:

   占资源: 每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

  ② 扩展性弱:用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

  ③ CSRF攻击:因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。

Json Web Token

  基于token的鉴权机制:基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

流程上是这样的:

  • 用户使用用户名密码来请求服务器
  • 服务器进行验证用户的信息
  • 服务器通过验证发送给用户一个token
  • 客户端存储token,并在每次请求时附送上这个token值
  • 服务端验证token值,并返回数据

  这个token必须要在每次请求时传递给服务端,它应该保存在请求头里, 另外,服务端要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *

JWT长什么样?

  JWT是由三段信息构成的,将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
# 头部(header). 载荷(payload). 签证(signature)

  第一部分我们称它为头部(header),第二部分我们称其为载荷(payload, 类似于飞机上承载的物品),第三部分是签证(signature).

JWT的构成

① header :jwt的头部承载两部分信息

  --> 声明类型,这里是jwt

  --> 声明加密的算法 通常直接使用 HMAC SHA256

  -->完整的头部就像下面这样的JSON:

  -->然后将头部进行base64加密(该加密是可以对称解密的),构成了第一部分.

# 完整的头部示例
{
  ‘typ‘: ‘JWT‘,
  ‘alg‘: ‘HS256‘
}
# 加密后的头部
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

② payload:载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

  --> 标准中的注册的声明

    • iss: jwt签发者
    • sub: jwt所面向的用户
    • aud: 接收jwt的一方
    • exp: jwt的过期时间,这个过期时间必须要大于签发时间
    • nbf: 定义在什么时间之前,该jwt都是不可用的.
    • iat: jwt的签发时间
    • jti: jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。

  --> 公共的声明:可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.

  --> 私有的声明:私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为明文信息。

# 一个完整的payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

# base64加密后
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

③ signature:JWT的第三部分是一个签证信息,这个签证信息由三部分组成

  --> header (base64后的)

  --> payload (base64后的)

    --> secret

  这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串,然后通过header中声明的加密方式进行加盐secret组合加密,然后就构成了jwt的第三部分。

// javascript
var encodedString = base64UrlEncode(header) + ‘.‘ + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, ‘secret‘); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

  将这三部分用.连接成一个完整的字符串,构成了最终的jwt:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

  注意:secret是保存在服务器端的,jwt的签发生成也是在服务器端的,secret就是用来进行jwt的签发和jwt的验证,所以,它就是你服务端的私钥,在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

如何应用

一般是在请求头里加入Authorization,并加上Bearer标注:

fetch(‘api/user/1‘, {
  headers: {
    ‘Authorization‘: ‘Bearer ‘ + token
  }
})

服务端会验证token,如果验证通过就会返回相应的资源。整个流程就是这样的:

优点

 ①  因为json的通用性,所以JWT是可以进行跨语言支持的,像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。

   ②  因为有了payload部分,所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。

   ③  便于传输,jwt的构成非常简单,字节占用很小,所以它是非常便于传输的。

   ④  它不需要在服务端保存会话信息, 所以它易于应用的扩展

安全相关

  ① 不应该在jwt的payload部分存放敏感信息,因为该部分是客户端可解密的部分。

  ② 保护好secret私钥,该私钥非常重要。

  ③ 如果可以,请使用https协议

原文地址:https://www.cnblogs.com/Jaho/p/9275986.html

时间: 2024-09-28 16:27:47

基于token的鉴权机制 — JWT介绍的相关文章

IMS AKA鉴权及应用流程详解

IMS AKA鉴权及应用流程详解 @auth doubleRabbit @date 2017-03-14 目的 了解鉴权及通信类业务相关鉴权算法的概念原理 了解IMS注册流程 了解IMS鉴权流程应用 鉴权含义 鉴权是指用户访问系统的权利,是提升系统安全性的一种方式,传统鉴权方法就是用户名与密码. 鉴权与授权的区别联系.逻辑上授权过程发生在鉴权之后,而实际中有时鉴权与授权对于用户来说体现为同一过程.例如在EPC附着过程中,先发生AIA鉴权过程,再发生ULR位置更新过程(授权). 接下来讲的是针对通

鉴权,开放式授权,单点登陆

鉴权 鉴权(authentication)是指验证用户是否拥有访问系统的权利.传统的鉴权是通过密码来验证的.这种方式的前提是,每个获得密码的用户都已经被授权.在建立用户时,就为此用户分配一个密码,用户的密码可以由管理员指定,也可以由用户自行申请.这种方式的弱点十分明显:一旦密码被偷或用户遗失密码,情况就会十分麻烦,需要管理员对用户密码进行重新修改,而修改密码之前还要人工验证用户的合法身份. 为了克服这种鉴权方式的缺点,需要一个更加可靠的鉴权方式.目前的主流鉴权方式是利用认证授权来验证数字签名的正

公共平台服务治理与鉴权

问题 解决问题 鉴权 注册 管理 总结 聊一聊最近了解的公司服务治理平台,主要是思想,理念,而不是一种技术或框架.整个平台设计,融入了OAUTH2认证,融入了微服务思想,帮助公司各系统在复杂的IT架构下,实现一种便捷统一的调用方案,同时完成调用的管理(监控.注册.鉴权等). 问题 一种思想或理念的出现,是否有价值,我认为主要在于它实际解决了哪些问题.基于这个价值观,我们先看看,当一个公司有成百上千个系统时,会有哪些问题? pi如: 接口访问有没有鉴权?如何鉴权?这个话题很大,归根揭底就是,要让提

接口交互鉴权以及数据处理

总言:一般只要是 2端(调用方和被调用方)分离的 ,无论是后端对后端 还是前端对后端  或者终端对后端  正常的接口都需要有个鉴权,数据加解的过程 1.身份标识符 1.1.token方式鉴权  token作为身份标识符, 备注:一般程序会有登陆模块,或者身份认证模块 ,调用认证接口  接口提供方 向 调用方下发token  作为身份标识符,后续需要鉴权接口带上token,以此为凭证依据:token 有一定的生命周期(有效期) ,和具体的或者独有的生成规则( token 生成有独立的规则 可以带上

使用JWT 进行基于 Token 的身份验证方法

一般weby应用服务都使用有状态的session来存储用户状态以便认证有权限的用户进行的操作.但服务器在做横向扩展时,这种有状态的session解决方案就受到了限制.所以在一些通常的大型web应用场景越来越多在采用没有状态的token来进行用户签权处理. 需要把Web应用做成无状态的,即服务器端无状态,就是说服务器端不会存储像会话这种东西,而是每次请求时access_token进行资源访问.这里我们将使用 JWT 1,基于散列的消息认证码,使用一个密钥和一个消息作为输入,生成它们的消息摘要.该密

服务器认证、授权、鉴权、session、token

1.session(赛神)会话机制 session 会话机制会借助 cookie + session 一起来做认证 cookie 是放在浏览器中的,cookie 是存储在客服端,但是可以由服务端和客户端生成. sesion 是保存在服务端的数据库中的,session 是服务端一块存储空间,只能由服务端生成. session 是把 session id 也就是session 的 key 值,保存到 cookie 当中 这个 key 值 一般在访问其他页面的时候会放到 cookie 当中,向后端发起

物联网架构成长之路(56)-SpringCloudGateway+JWT实现网关鉴权

0. 前言 结合前面两篇博客,前面博客实现了Gateway网关的路由功能.此时,如果每个微服务都需要一套帐号认证体系就没有必要了.可以在网关处进行权限认证.然后转发请求到后端服务.这样后面的微服务就可以直接调用,而不需要每个都单独一套鉴权体系.参考了Oauth2和JWT,发现基于微服务,使用JWT会更方便一些,所以准备集成JWT作为微服务架构的认证方式. [https://www.cnblogs.com/wunaozai/p/12512753.html] 物联网架构成长之路(54)-基于Naco

开放平台鉴权以及OAuth2.0介绍

OAuth 2.0 协议 OAuth是一个开发标准,允许用户授权第三方网站或应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方网站或分享他们数据的内容. OAuth 2.0不兼容1.0. 协议的参与者 RO (resource owner): 资源所有者,对资源具有授权能力的人. RS (resource server): 资源服务器,它存储资源,并处理对资源的访问请求. Client: 第三方应用,它获得RO的授权后便可以去访问RO的资源. AS (authoriz

基于Token的WEB后台认证机制

几种常用的认证机制 HTTP Basic Auth HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password,简言之,Basic Auth是配合RESTful API 使用的最简单的认证方式,只需提供用户名密码即可,但由于有把用户名密码暴露给第三方客户端的风险,在生产环境下被使用的越来越少.因此,在开发对外开放的RESTful API时,尽量避免采用HTTP Basic Auth OAuth OAuth(开放授权)是一个开放的授权标准,允许用户让