CN109450865A - 基于jwt验证的api用户认证方法 - Google Patents

Abstract

本发明公开了一种基于JWT验证的API用户认证方法，包括以下步骤：S1：用户登录时验证用户，验证用户通过后获取token返回给客户端；S2：创建拦截器中间件并验证token的正确性；S3：根据业务需求给不同的路由添加拦截器中间件。本发明在用户登录过程中使用JWT验证，对客户端伪造cookie信息进行了有效的防范，提高了项目的安全性；同时在数据接口中使用JWT验证，可以根据相关的业务去配置token过期时间，提高数据的安全性同时，也可以满足业务的灵活性。

Description

基于JWT验证的API用户认证方法

技术领域

本发明涉及API验证技术领域，具体涉及基于JWT验证的API用户认证方法。

背景技术

Cookie+Session的存在主要是为了解决HTTP这一无状态协议下服务器如何识别用户的问题，其原理就是在用户登录通过验证后，服务端将数据加密后保存到客户端浏览器的Cookie中，同时服务器保留相对应的Session（文件或DB）。用户之后发起的请求都会携带Cookie信息，服务端需要根据Cookie寻回对应的Session，从而完成验证，确认这是之前登陆过的用户。

目前这种API认证方式存在以下缺点：不适合长期身份认证和短期资源、路由的认证；不适合分布式应用和多端应用；不能跨越应用和单点登录。

发明内容

本发明的目的在于提供一种基于JWT验证的API用户认证方法，解决目前的认证方式不适合长期身份认证和短期资源、路由的认证，不适合分布式应用和多端应用，不能跨越应用和单点登录的问题。

为解决上述的技术问题，本发明采用以下技术方案：

一种基于JWT验证的API用户认证方法，包括以下步骤：

S1：用户登录时验证用户，验证用户通过后获取token返回给客户端；

S2：创建拦截器中间件并验证token的正确性；

S3：根据业务需求给不同的路由添加拦截器中间件。

作为优选，所述token的结构包括头部、负荷和签名，具体结构为xxxxx.yyyyy.zzzzz，所述头部用于描述token类型和加密算法，所述负荷用于放置token有效信息，所述签名用于将头部和负荷编码后进行加密。

作为优选，所述S1步骤中，客户接收到token值后保存该token值，并在下次请求时带上该token值。

作为优选，所述S2步骤中拦截器中间件验证token正确性的方法是：首先请求路由地址，并验证token的正确性，验证成功后跳转到请求的页面，请求结束后重新生成token值返回给客户端，验证失败则返回错误信息。

作为优选，客户端能够单独请求路由生成token。

与现有技术相比，本发明的有益效果是：

本发明在用户登录过程中使用JWT验证，对客户端伪造cookie信息进行了有效的防范，提高了项目的安全性。

本发明在数据接口中使用JWT验证，可以根据相关的业务去配置token过期时间，提高数据的安全性同时，也可以满足业务的灵活性。

本发明项目中的用户信息不需要存储session，因为Token本身包含了项目中需要的用户信息。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

针对本发明的实施例，一种基于JWT验证的API用户认证方法，包括以下步骤：

用户登录时首先验证用户，验证用户通过后获取token返回给客户端。客户端接收到token保存，下次请求数据的时候带上token值。

创建拦截器中间件，中间件中需要验证token的正确性，验证通过后跳转到请求的页面，请求结束后需要重新生成token值一起返回给客户端。验证失败后返回错误信息。

if($tokenUserId == $userId){

//请求路由地址 $response = $next($request, $response);

//响应结束后重新生成token返回给客户端 $token = generateToken($key,$expiredtimeaccess,$userId,$algs);return $response->withHeader('Authorization', $token);}else{return $response->withJson(array('status' => '203', 'error' => getHttpStatusMessage(203)));}

3、根据业务需求给不同的路由添加拦截器。项目中有关业务需求请求数据的路由都需要添加拦截器，保证数据的安全性。

$app->get('/playBack/{user_id}/{subplan_id}','ChinaEdu\Action\ClassTodayAction:playBack')->add($mw)

4、客户端也可以单独请求路由生成token。

JWT作为中间件的好处是减少了JWT验证与项目的耦合性，同时提高了项目本身的可读性。

对于某些应用的架构是多端的，有web页面端、移动端，各端的部署有不同的域名，数据的存取需要用REST架构风格、json数据格式，获取服务器资源以及访问路由，并且，业务要求当用户用自己的用户名和密码登录后需要在一段时间能不需要重新登录（一周或一个月内）。在此背景下为了克服上述缺点是这样实现的：

在客户端在http协议header的Authoriztion字段带着resourceToken去权限服务器认证resourceToken的合法性和检查resourceToken的期限的有效性，如果通过JWT的验证和检验，resourceToken是合法有效的，就会根据相应的参数取到资源，并且权限服务器通过JWT生成新的resourceToken，这个新的resourceToken是根据JWT原理和业务相关的需求生成一个有生存周期的资源认证的Token，这个生存周期可能是10分钟，也可能是2个小时，由相关的业务去配置。客户端在获得资源的同时也获得一个新的resourceToken，客户端会把这个resourceToken保存到本地的localStorage，以便下次资源请求时进行认证。如果通过JWT验证resourceToken超过生存周期，客户端就从本地localStorage取到登录授权时的authToken，用authToken作为http协议header的Authoriztion的字段去权限服务认证，如果认证通过，客户端就会取到资源并且权限服务返回给一个新的resourceToken，作为下次资源请求的认证；如果JWT验证authToken周期过期或有数据篡改，权限服务器就要求客户端重新用用户名和密码登录，权限服务器通过用户名和密码验证用户权限和身份后会根据业务逻辑通过JWT生成authToken，authTonken被客户端保存在本地的localStorage，authToken的生命周期一般比较长，一周或是一个月，这样做可以避免用户使用移动端时多次登录授权认证，只要用户每次使用移动端时，客户端在http协议的header中的Authoriztion字段带着本地的authToken的去权限服务器通过JWT认证，认证通过用户就是合法的授权使用者。

学酷API授权认证的实现是建立在JWT（JSON Web Token）基础上的，JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准（ RFC 7519 ），定义了一种简洁的，自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。

API认证使用JWT的原因是：

体积小，因而传输速度快。

传输方式多样，可以通过 URL/POST 参数/HTTP 头部 等方式传输。

严谨的结构化。它自身（在 payload 中）就包含了所有与用户相关的验证消息，如用户可访问路由、访问有效期等信息，服务器无需再去连接数据库验证信息的有效性，并且payload 支持为你的应用而定制化。

支持跨域验证，多应用于单点登录。

充分依赖无状态 API，契合 RESTful 设计原则。

验证解耦，无需使用特定的身份验证方案，易于实现分布式。

比 cookie 更支持原生移动端应用。

<二.>JWT结构是头部(Header)、负荷(Payload)、签名(Signature)三部分构成结构如下：xxxxx.yyyyy.zzzzz。

头部(Header)用来描述token类型和加密算法(HMAC、SHA256、RSA)，如下：

{

"alg": "HS256",

"typ": "JWT"

}

负荷(Payload)这部分用来放置token的有效信息，有reserved，public，private三种类型：

Reserved claims： 一些保留类型的，推荐但不强制必须使用，包括以下属性

iss: jwt签发者

sub: jwt所面向的用户

aud: 接收jwt的一方

exp: jwt的过期时间，这个过期时间必须要大于签发时间

nbf: 定义在什么时间之前，该jwt都是不可用的.

iat: jwt的签发时间

jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

Public claims： 可以随意定义的属性, 但为了避免冲突，他们应该使用 IANAJSON Web Token Registry 定义或使用 URL 定义。

Private claims: 这些是为了在同意使用它们的各方之间共享信息而创建的自定义声明。

如下：

{

"iss": "a.com",

"exp": "expireDate",

"http://a.com": true,

"company": "A",

"awesome": true

}

签名(Signature)将Header、Payload编码后加上secret，并用Header声明的算法进行加密，生成的签名如下:HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

最后Token 有base64（Header）. base64（Payload）. Signature生成如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

JWT的认证原理：

在身份验证中，当用户成功地使用它们的密码登录后，一个JSON Web Token就会被服务器返回，且必须存储于客户端本地（通常存于localStorage，也可以使用cookie存储），而不是传统做法中在服务器创建一个session，并返回一个cookie。无论何时用户想要访问一个受保护的路由或资源，客户端应该随请求一起发送JWT。JWT通常在 AuthenticationHTTP头部中，使用 Bearer 格式（schema）存放。HTTP头部的内容可能长这样：Authorization: token这是一个无状态（stateless）的认证机制，因为用户状态并未存放在服务器内存中。服务器的受保护路由会在Authentication头部中检查是否存在合法的JWT，如果存在，用户就被允许访问受保护的资源。JWT是自包含的，所以相关的信息都在里面，减少了多次查询数据库的必要。这让你充分可以依赖无状态的数据API，甚至向下游服务发出请求。哪个域名提供API无所谓，所以跨域资源共享（CORS，Cross-Origin ResourceSharing）不会引起麻烦，因为JWT不使用cookie。

本发明在用户登录过程中使用JWT验证，对客户端伪造cookie信息进行了有效的防范，提高了项目的安全性。

本发明在数据接口中使用JWT验证，可以根据相关的业务去配置token过期时间，提高数据的安全性同时，也可以满足业务的灵活性。

本发明项目中的用户信息不需要存储session，因为Token本身包含了项目中需要的用户信息。

尽管这里参照本发明的解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说，在本申请公开和权利要求的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变形和改进外，对于本领域技术人员来说，其他的用途也将是明显的。

Claims (5)

1.一种基于JWT验证的API用户认证方法，其特征在于：包括以下步骤：

S1：用户登录时验证用户，验证用户通过后获取token返回给客户端；

S2：创建拦截器中间件并验证token的正确性；

S3：根据业务需求给不同的路由添加拦截器中间件。

2.根据权利要求1所述的基于JWT验证的API用户认证方法，其特征在于：所述token的结构包括头部、负荷和签名，具体结构为xxxxx.yyyyy.zzzzz，所述头部用于描述token类型和加密算法，所述负荷用于放置token有效信息，所述签名用于将头部和负荷编码后进行加密。

3.根据权利要求1所述的基于JWT验证的API用户认证方法，其特征在于：所述S1步骤中，客户接收到token值后保存该token值，并在下次请求时带上该token值。

4.根据权利要求1所述的基于JWT验证的API用户认证方法，其特征在于：所述S2步骤中拦截器中间件验证token正确性的方法是：首先请求路由地址，并验证token的正确性，验证成功后跳转到请求的页面，请求结束后重新生成token值返回给客户端，验证失败则返回错误信息。

5.根据权利要求1所述的基于JWT验证的API用户认证方法，其特征在于：客户端能够单独请求路由生成token。