JWT 笔记

2017-04-20  本文已影响0人  Cause_XL

JWT 笔记

***参考链接

参考链接1

参考链接2

官方库

当使用一个API时,其中一个挑战就是认证(authentication)。在传统的web应用中,服务端成功的返回一个响应(response)依赖于两件事。一是,他通过一种存储机制保存了会话信息(Session)。每一个会话都有它独特的信息(id),常常是一个长的,随机化的字符串,它被用来让未来的请求(Request)检索信息。其次,包含在响应头(Header)里面的信息使客户端保存了一个Cookie。服务器自动的在每个子请求里面加上了会话ID,这使得服务器可以通过检索Session中的信息来辨别用户。这就是传统的web应用逃避HTTP面向无连接的方法。

Token

不是在每一次请求时提供用户名和密码的凭证。我们可以让用户通过token交换凭证(we can allow the client to exchange valid credentials for a token),这个token提供用户访问服务器的权限。Token通常比密码更加长而且复杂。比如说,JWTs通常会应对长达150个字符。一旦获得了token,在每次调用API的时候都要附加上它。然后,这仍然比直接发送账户和密码更加安全,哪怕是HTTPS。

把token想象成一个安全的护照。你在一个安全的前台验证你的身份(通过你的用户名和密码),如果你成功验证了自己,你就可以取得这个。当你走进大楼的时候(试图从调用API获取资源),你会被要求验证你的护照,而不是在前台重新验证。

什么是 JWT ?

JWT -- JSON Web Token,它是基于 RFC 7519 所定义的一种在各个系统中传递紧凑和自包含的 JSON 数据形式。

JSON Web Token 由三部分组成使用 . 分割开:

一个 JWT 形式上类似于下面的样子:

xxxxx.yyyy.zzzz

Header 一般由两个部分组成:

alg 是指所使用的 hash 算法,例如 HMAC SHA256 或 RSA,typ 是 Token 的类型。

{
  "alg": "HS256",
  "typ": "JWT"
}

然后使用 Base64Url 编码成第一部分。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>

Payload

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

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

一个 Pyload 可以是这样子的:

{
  "iss": "joe",
  "exp": 1300819380,
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
  "iat": 1441593502,
  "aud": "www.example.com",
  "from_user": "B",
  "target_user": "A"
}

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>

Signature

在创建该部分时候你应该已经有了 编码后的 Header 和 Payload 还需要一个秘钥,这个加密的算法应该 Header 中指定。

一个使用 HMAC SHA256 的例子如下:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

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

所以,最后你的一个完整的 JWT 应该是如下形式:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意�被 . 分割开的三个部分

上一篇下一篇

猜你喜欢

热点阅读