JSON Web Token 简介

在API驱动开发的今天，针对API的验证受权愈来愈重要，这是保证数据安全第一步。基于token受权的机制随着实践的不断进步也推陈出新，其中较为人知的有：

• HTTP Basic
• API Key
• OAuth2
• JSON Web Token(JWT)

他们都有各自不一样适用场景，此处仅对JWT进行抛砖引玉简单介绍。

JWT是Internet Engineering Task Force(IETF)制定的开放标准，归档为RFC 7519

JWT两大优势：

• 小巧：因为尺寸较小，JWT能够经过URL，POST参数或HTTP标头内发送。另外，尺寸越小意味着传输速度越快。
• 自包含：Token的载荷部分能够包含有关用户的全部必需信息，避免了屡次查询数据库的须要

JWT基本结构

1. Header(头部)
2. Payload(荷载）
3. Signature(签名)

jwt最终造成的字符串结构如：xxxxx.yyyyy.zzzzz，每一部分都是基于base64url编码的值。

Header部分

一般状况下Header部分会包含两个值，typ表示token类型，alg表示hash算法，如：

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

Payload部分

这部分是包含声明数据的有效荷载，共有有三种声明数据：Registered、Public、Private，全部的声明数据都不是必须的。

Registered

此种类型的声明是预先定义的，每个都有特定的含义。此种类型的声明每每是推荐使用的，由于他们让JWT的数据更合理。目前已经注册的类型有：

• iss：issuer的简写，表示发行JWT的主体方
• sub：subject的简写，表示该JWT的主题，该值需在上下文中惟一或全局惟一
• aud：audience的简写，表示该JWT的接收人
• exp：expiration的简写，表示过时时间，其值必须为Unix时间戳
• nbf：not before的简写，表示JWT生效时间，其值必须为Unix时间戳
• iat：issued at的简写，表示JWT的发行时间
• jti：JWT ID的简写，表示JWT的惟一标识

Public

此种类型的声明可由JWT的使用者随意定义，但一般状况下为了不冲突，咱们须要使用IANA JSON Web Token Registry中已注册的，或者被定义为包含抗冲突命名空间的URI。

Private

此种类型的声明可由JWT的使用者随意定义，但一般状况下咱们须要使用Registered和Public以外的。

{
    "iss": "api",
    "exp": 1300819380,
    "email": "test@email.com",
    "hobby": "basketball"
}

Signature部分

要建立签名部分，必须采用已编码的Header、已编码的Payload、密匙、签名算法。

签名的计算逻辑：

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

从上面的计算方法能够看出，JWT只保证数据的不可串改，不保证数据不可窥探。假如咱们的secret值为‘password'，那么由本篇内容中罗列的示例数据计算出的最终JWT值为：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJhcGkiLCJleHAiOjEzMDA4MTkzODAsImVtYWlsIjoidGVzdEBlbWFpbC5jb20iLCJob2JieSI6ImJhc2tldGJhbGwifQ.hKYJybV4u0Rc4oIB7l7LKbHWbKlMM1dkquq53MM5N2Q

咱们能够在JWT Debugger进行验证.

JWT的使用

JWT能够经过任何方式从客户端发送到服务器，但一般在API的验证流程中使用HTTP-Bearer

Authorization: Bearer <token>

下图展现了完整的流程：