当前位置: 移动技术网 > IT编程>软件设计>架构 > BearerToken之JWT的介绍

BearerToken之JWT的介绍

2019年07月26日  | 移动技术网IT编程  | 我要评论
Bearer认证 HTTP提供了一套标准的身份验证框架:服务器可以用来针对客户端的请求发送质询(challenge),客户端根据质询提供身份验证凭证。质询与应答的工作流程如下:服务器端向客户端返回401(Unauthorized,未授权)状态码,并在WWW Authenticate头中添加如何进行验 ...

bearer认证

http提供了一套标准的身份验证框架:服务器可以用来针对客户端的请求发送质询(challenge),客户端根据质询提供身份验证凭证。质询与应答的工作流程如下:服务器端向客户端返回401(unauthorized,未授权)状态码,并在www-authenticate头中添加如何进行验证的信息,其中至少包含有一种质询方式。然后客户端可以在请求中添加authorization头进行验证,其value为身份验证的凭证信息。

在http标准验证方案中,我们比较熟悉的是"basic"和"digest",前者将用户名密码使用base64编码后作为验证凭证,后者是basic的升级版,更加安全,因为basic是明文传输密码信息,而digest是加密后传输。在前文介绍的cookie认证属于form认证,并不属于http标准验证。

本文要介绍的bearer验证也属于http协议标准验证,它随着oauth协议而开始流行,详细定义见: rfc 6570

     +--------+                               +---------------+
     |        |--(a)- authorization request ->|   resource    |
     |        |                               |     owner     |
     |        |<-(b)-- authorization grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(c)-- authorization grant -->| authorization |
     | client |                               |     server    |
     |        |<-(d)----- access token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(e)----- access token ------>|    resource   |
     |        |                               |     server    |
     |        |<-(f)--- protected resource ---|               |
     +--------+                               +---------------+

                     figure 1: abstract protocol flow

bearer验证中的凭证称为bearer_token,或者是access_token,它的颁发和验证完全由我们自己的应用程序来控制,而不依赖于系统和web服务器,bearer验证的标准请求方式如下:

authorization: bearer [bearer_token] 

jwt(json web token)

上面介绍的bearer认证,其核心便是bearer_token,而最流行的token编码方式便是:json web token。

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

  1. 头部 header
  2. 载荷 payload
  3. 签名 signature

jwt token包含了使用.分隔的三部分

{header 头部}.{payload 负载}.{signature 签名}

头部 header

header 一般由两个部分组成:

  1. alg
  2. typ

alg是是所使用的hash算法,如:hmac sha256或rsa,typ是token的类型,在这里就是:jwt。

{
  "alg": "hs256",
  "typ": "jwt"
}

然后使用base64url编码成第一部分

eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.<second part>.<third part>

载荷 payload

这一部分是jwt主要的信息存储部分,其中包含了许多种的声明(claims)。

claims的实体一般包含用户和一些元数据,这些claims分成三种类型:

  1. reserved claims:预定义的 一些声明,并不是强制的但是推荐,它们包括 iss (issuer), exp (expiration time), sub (subject),aud(audience) 等(这里都使用三个字母的原因是保证 jwt 的紧凑)。
  2. public claims: 公有声明,这个部分可以随便定义,但是要注意和 iana json web token 冲突。
  3. private claims: 私有声明,这个部分是共享被认定信息中自定义部分。

一个简单的pyload可以是这样子的:

{
   "user_name": "admin", 
   "scope": [
       "read","write","del"
   ], 
   "organization": "admin", 
   "exp": 1531975621, 
   "authorities": [
       "admin"
   ], 
   "jti": "23408d38-8cdc-4460-beac-24c76dc7629a", 
   "client_id": "webapp"
}

这部分同样使用base64url编码成第二部分

eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjzdwiioiixmjm0nty3odkwiiwibmftzsi6ikpvag4grg9liiwiywrtaw4ionrydwv9.<third part>

签名 signature

signature是用来验证发送者的jwt的同时也能确保在期间不被篡改。

使用base64编码后的header和payload以及一个秘钥,使用header中指定签名算法进行签名。

eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjzdwiioiixmjm0nty3odkwiiwibmftzsi6ikpvag4grg9liiwiywrtaw4ionrydwv9.tjva95orm7e2cbab30rmhrhdcefxjoyzgefonfh7hgq

因此使用jwt具有如下好处:

  1. 通用:因为json的通用性,所以jwt是可以进行跨语言支持的,像java,javascript,nodejs,php等很多语言都可以使用。
  2. 紧凑:jwt的构成非常简单,字节占用很小,可以通过 get、post 等放在 http 的 header 中,非常便于传输。
  3. 扩展:jwt是自我包涵的,包含了必要的所有信息,不需要在服务端保存会话信息, 非常易于应用的扩展。

如您对本文有疑问或者有任何想说的,请点击进行留言回复,万千网友为您解惑!

相关文章:

验证码:
移动技术网