WEB后台基于Token的WEB后台登录认证机制（并讲解其他认证机制以及cookie和session机制）

继续这一个系列&＃xff0c;基于Token的WEB后台登录认证机制&＃xff08;并讲解COOKIE和session机制&＃xff09;。每个后端不得不解决的认证问题。

本系列&＃xff1a;

&＃xff08;一&＃xff09;J2EE项目系列&＃xff08;三&＃xff09;–Spring Data JPA&＃43;Spring&＃43;SpringMVC&＃43;Maven快速开发&＃xff08;1&＃xff09;项目架构

&＃xff08;二&＃xff09; J2EE项目系列&＃xff08;三&＃xff09;–Spring Data JPA&＃43;Spring&＃43;SpringMVC&＃43;Maven快速开发&＃xff08;2&＃xff09;多个第三方服务端接入之云旺IM

&＃xff08;三&＃xff09; Java-解决实现JPA的hibernate自动建表的编码问题

文章结构&＃xff1a;

&＃xff08;1&＃xff09;JWT&＃xff08;一种基于 token 的认证方案&＃xff09;介绍并介绍其他几大认证机制&＃xff1b;
&＃xff08;2&＃xff09;COOKIE和session机制&＃xff1b;
&＃xff08;3&＃xff09;Token机制相对于COOKIE机制的好处&＃xff1b;
&＃xff08;4&＃xff09;JWT的Java实现&＃xff1b;

一、JWT&＃xff08;一种基于 token 的认证方案&＃xff09;介绍&＃xff1a;

&＃xff08;1&＃xff09;概述&＃xff1a;

JWT就是一种Token的编码算法&＃xff0c;服务器端负责根据一个密码和算法生成Token&＃xff0c;然后发给客户端&＃xff0c;客户端只负责后面每次请求都在HTTP header里面带上这个Token&＃xff0c;服务器负责验证这个Token是不是合法的&＃xff0c;有没有过期等&＃xff0c;并可以解析出subject和claim里面的数据。

&＃xff08;2&＃xff09;相关问题&＃xff1a;

1.为什么用JWT&＃xff1f;

JWT只通过算法实现对Token合法性的验证&＃xff0c;不依赖数据库&＃xff0c;Memcached的等存储系统&＃xff0c;因此可以做到跨服务器验证&＃xff0c;只要密钥和算法相同&＃xff0c;不同服务器程序生成的Token可以互相验证。

2.JWT Token不需要持久化在任何NoSQL中&＃xff0c;不然背离其算法验证的初心

3.在退出登录时怎样实现JWT Token失效呢&＃xff1f;

退出登录&＃xff0c; 只要客户端端把Token丢弃就可以了&＃xff0c;服务器端不需要废弃Token。

4.怎样保持客户端长时间保持登录状态&＃xff1f;

服务器端提供刷新Token的接口&＃xff0c; 客户端负责按一定的逻辑刷新服务器Token。

5.服务器端是否应该从JWT中取出userid用于业务查询&＃xff1f;

REST API是无状态的&＃xff0c;意味着服务器端每次请求都是独立的&＃xff0c;即不依赖以前请求的结果&＃xff0c;因此也不应该依赖JWT token做业务查询&＃xff0c; 应该在请求报文中单独加个userid 字段。

为了做用户水平越权的检查&＃xff0c;可以在业务层判断传入的userid和从JWT token中解析出的userid是否一致&＃xff0c; 有些业务可能会允许查不同用户的数据。

&＃xff08;3&＃xff09;其他几大认证机制&＃xff1a;

1.HTTP Basic Auth&＃xff1a;

HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password&＃xff0c;简言之&＃xff0c;Basic Auth是配合RESTful API 使用的最简单的认证方式&＃xff0c;只需提供用户名密码即可&＃xff0c;但由于有把用户名密码暴露给第三方客户端的风险&＃xff0c;在生产环境下被使用的越来越少。因此&＃xff0c;在开发对外开放的RESTful API时&＃xff0c;尽量避免采用HTTP Basic Auth

2.OAuth&＃xff08;开放授权&＃xff09;&＃xff1a;

是一个开放的授权标准&＃xff0c;允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源&＃xff08;如照片&＃xff0c;视频&＃xff0c;联系人列表&＃xff09;&＃xff0c;而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌&＃xff0c;而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统&＃xff08;例如&＃xff0c;视频编辑网站)在特定的时段&＃xff08;例如&＃xff0c;接下来的2小时内&＃xff09;内访问特定的资源&＃xff08;例如仅仅是某一相册中的视频&＃xff09;。这样&＃xff0c;OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息&＃xff0c;而非所有内容。

这种基于OAuth的认证机制适用于个人消费者类的互联网产品&＃xff0c;如社交类APP等应用&＃xff0c;但是不太适合拥有自有认证权限管理的企业应用&＃xff1b;

3.COOKIE Auth&＃xff1a;

COOKIE认证机制就是为一次请求认证在服务端创建一个Session对象&＃xff0c;同时在客户端的浏览器端创建了一个COOKIE对象&＃xff1b;通过客户端带上来COOKIE对象来与服务器端的session对象匹配来实现状态管理的。默认的&＃xff0c;当我们关闭浏览器的时候&＃xff0c;COOKIE会被删除。但可以通过修改COOKIE 的expire time使COOKIE在一定时间内有效&＃xff1b;

二、COOKIE和session机制&＃xff1a;

&＃xff08;1&＃xff09;概述&＃xff1a;

COOKIE和Session是为了在无状态的HTTP协议之上维护会话状态&＃xff0c;使得服务器可以知道当前是和哪个客户在打交道。

Session是在服务端保存的一个数据结构&＃xff0c;用来跟踪用户的状态&＃xff0c;这个数据可以保存在集群、数据库、文件中&＃xff1b;

COOKIE是客户端保存用户信息的一种机制&＃xff0c;用来记录用户的一些信息&＃xff0c;也是实现Session的一种方式。

因为HTTP协议是无状态的&＃xff0c;即每次用户请求到达服务器时&＃xff0c;HTTP服务器并不知道这个用户是谁、是否登录过等。现在的服务器之所以知道我们是否已经登录&＃xff0c;是因为服务器在登录时设置了浏览器的COOKIE&＃xff01;Session则是借由COOKIE而实现的更高层的服务器与浏览器之间的会话。

&＃xff08;2&＃xff09;COOKIE实现机制&＃xff1a;

COOKIE是由客户端保存的小型文本文件&＃xff0c;其内容为一系列的键值对。 COOKIE是由HTTP服务器设置的&＃xff0c;保存在浏览器中&＃xff0c; 在用户访问其他页面时&＃xff0c;会在HTTP请求中附上该服务器之前设置的COOKIE。

COOKIE的传递流程&＃xff1a;

1.浏览器向某个URL发起HTTP请求&＃xff08;可以是任何请求&＃xff0c;比如GET一个页面、POST一个登录表单等&＃xff09;

2.对应的服务器收到该HTTP请求&＃xff0c;并计算应当返回给浏览器的HTTP响应。&＃xff08;HTTP响应包括请求头和请求体两部分&＃xff09;

3.在响应头加入Set-COOKIE字段&＃xff0c;它的值是要设置的COOKIE。

4.浏览器收到来自服务器的HTTP响应。

5.浏览器在响应头中发现Set-COOKIE字段&＃xff0c;就会将该字段的值保存在内存或者硬盘中。&＃xff08;Set-COOKIE字段的值可以是很多项COOKIE&＃xff0c;每一项都可以指定过期时间Expires。 默认的过期时间是用户关闭浏览器时。&＃xff09;

6.浏览器下次给该服务器发送HTTP请求时&＃xff0c; 会将服务器设置的COOKIE附加在HTTP请求的头字段COOKIE中。&＃xff08;浏览器可以存储多个域名下的COOKIE&＃xff0c;但只发送当前请求的域名曾经指定的COOKIE&＃xff0c; 这个域名也可以在Set-COOKIE字段中指定&＃xff09;。&＃xff09;

7.服务器收到这个HTTP请求&＃xff0c;发现请求头中有COOKIE字段&＃xff0c; 便知道之前就和这个用户打过交道了.

8.过期的COOKIE会被浏览器删除。

总之

服务器通过Set-COOKIE响应头字段来指示浏览器保存COOKIE&＃xff0c; 浏览器通过COOKIE请求头字段来告诉服务器之前的状态。 COOKIE中包含若干个键值对&＃xff0c;每个键值对可以设置过期时间。

COOKIE 的安全隐患:

COOKIE提供了一种手段使得HTTP请求可以附加当前状态&＃xff0c; 现今的网站也是靠COOKIE来标识用户的登录状态的&＃xff1a;

1.用户提交用户名和密码的表单&＃xff0c;这通常是一个POST HTTP请求。

2.服务器验证用户名与密码&＃xff0c;如果合法则返回200&＃xff08;OK&＃xff09;并设置Set-COOKIE为authed&＃61;true。

3.浏览器存储该COOKIE。

4.浏览器发送请求时&＃xff0c;设置COOKIE字段为authed&＃61;true。

5.服务器收到第二次请求&＃xff0c;从COOKIE字段得知该用户已经登录。 按照已登录用户的权限来处理此次请求。

问题是什么&＃xff1f;&＃xff1f;风险是什么&＃xff1f;&＃xff1f;

我们知道可以发送HTTP请求的不只是浏览器&＃xff0c;很多HTTP客户端软件&＃xff08;包括curl、Node.js&＃xff09;都可以发送任意的HTTP请求&＃xff0c;可以设置任何头字段。 假如我们直接设置COOKIE字段为authed&＃61;true并发送该HTTP请求&＃xff0c; 服务器岂不是被欺骗了&＃xff1f;这种攻击非常容易&＃xff0c;COOKIE是可以被篡改的&＃xff01;

COOKIE 防篡改机制&＃xff1a;

服务器可以为每个COOKIE项生成签名&＃xff0c;由于用户篡改COOKIE后无法生成对应的签名&＃xff0c; 服务器便可以得知用户对COOKIE进行了篡改。

例子&＃xff1a;一个简单的校验过程&＃xff1a;

1.在服务器中配置一个不为人知的字符串&＃xff08;我们叫它Secret&＃xff09;&＃xff0c;比如&＃xff1a;x$sfz32。

2.当服务器需要设置COOKIE时&＃xff08;比如authed&＃61;false&＃xff09;&＃xff0c;不仅设置authed的值为false&＃xff0c; 在值的后面进一步设置一个签名&＃xff0c;最终设置的COOKIE是authed&＃61;false|6hTiBl7lVpd1P。

3.签名6hTiBl7lVpd1P是这样生成的&＃xff1a;Hash(‘x$sfz32’&＃43;‘true’)。 要设置的值与Secret相加再取哈希。

4.用户收到HTTP响应并发现头字段Set-COOKIE: authed&＃61;false|6hTiBl7lVpd1P。

5.用户在发送HTTP请求时&＃xff0c;篡改了authed值&＃xff0c;设置头字段COOKIE: authed&＃61;true|???。 因为用户不知道Secret&＃xff0c;无法生成签名&＃xff0c;只能随便填一个。

6.服务器收到HTTP请求&＃xff0c;发现COOKIE: authed&＃61;true|???。服务器开始进行校验&＃xff1a; Hash(‘true’&＃43;‘x$sfz32’)&＃xff0c;便会发现用户提供的签名不正确。

通过给COOKIE添加签名&＃xff0c;使得服务器得以知道COOKIE被篡改。但是&＃xff01;&＃xff01;还是有风险&＃xff01;

因为COOKIE是明文传输的&＃xff0c; 只要服务器设置过一次authed&＃61;true|xxxx我不就知道true的签名是xxxx了么&＃xff0c; 以后就可以用这个签名来欺骗服务器了。因此COOKIE中最好不要放敏感数据。 一般来讲COOKIE中只会放一个Session Id&＃xff0c;而Session存储在服务器端。

&＃xff08;3&＃xff09;session的实现机制&＃xff1a;

1.概述&＃xff1a;

Session 是存储在服务器端的&＃xff0c;避免了在客户端COOKIE中存储敏感数据。 Session 可以存储在HTTP服务器的内存中&＃xff0c;也可以存在内存数据库&＃xff08;如redis&＃xff09;中&＃xff0c; 对于重量级的应用甚至可以存储在数据库中。

例子&＃xff1a;存储在redis中的Session为例&＃xff0c;考察如何验证用户登录状态的问题。

1.用户提交包含用户名和密码的表单&＃xff0c;发送HTTP请求。

2.服务器验证用户发来的用户名密码。

3.如果正确则把当前用户名&＃xff08;通常是用户对象&＃xff09;存储到redis中&＃xff0c;并生成它在redis中的ID。

这个ID称为Session ID&＃xff0c;通过Session ID可以从Redis中取出对应的用户对象&＃xff0c; 敏感数据&＃xff08;比如authed&＃61;true&＃xff09;都存储在这个用户对象中。

4.设置COOKIE为sessionId&＃61;xxxxxx|checksum并发送HTTP响应&＃xff0c; 仍然为每一项COOKIE都设置签名。

5.用户收到HTTP响应后&＃xff0c;便看不到任何敏感数据了。在此后的请求中发送该COOKIE给服务器。

6.服务器收到此后的HTTP请求后&＃xff0c;发现COOKIE中有SessionID&＃xff0c;进行放篡改验证。

7.如果通过了验证&＃xff0c;根据该ID从Redis中取出对应的用户对象&＃xff0c; 查看该对象的状态并继续执行业务逻辑。

实现上述过程&＃xff0c;在Web应用中可以直接获得当前用户。 相当于在HTTP协议之上&＃xff0c;通过COOKIE实现了持久的会话。这个会话便称为Session。

三、Token认证机制相对于COOKIE等机制的好处&＃xff1a;

1. 支持跨域访问:

COOKIE是不允许垮域访问的&＃xff0c;这一点对Token机制是不存在的&＃xff0c;前提是传输的用户认证信息通过HTTP头传输。&＃xff08;垮域访问&＃xff1a;两个域名之间不能跨过域名来发送请求或者请求数据&＃xff09;

2.无状态(也称&＃xff1a;服务端可扩展行):

Token机制在服务端不需要存储session信息&＃xff0c;因为Token 自身包含了所有登录用户的信息&＃xff0c;只需要在客户端的COOKIE或本地介质存储状态信息.

3.更适用CDN:

可以通过内容分发网络请求你服务端的所有资料&＃xff08;如&＃xff1a;Javascript&＃xff0c;HTML,图片等&＃xff09;&＃xff0c;而你的服务端只要提供API即可.

4.去耦:

不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成&＃xff0c;只要在你的API被调用的时候&＃xff0c;你可以进行Token生成调用即可.

5.更适用于移动应用:

当你的客户端是一个原生平台&＃xff08;iOS, Android&＃xff0c;Windows 8等&＃xff09;时&＃xff0c;COOKIE是不被支持的&＃xff08;你需要通过COOKIE容器进行处理&＃xff09;&＃xff0c;这时采用Token认证机制就会简单得多。

6. CSRF:

因为不再依赖于COOKIE&＃xff0c;所以你就不需要考虑对CSRF&＃xff08;跨站请求伪造&＃xff09;的防范。

7.性能:

一次网络往返时间&＃xff08;通过数据库查询session信息&＃xff09;总比做一次HMACSHA256计算 的Token验证和解析要费时得多.

8.不需要为登录页面做特殊处理:

如果你使用Protractor 做功能测试的时候&＃xff0c;不再需要为登录页面做特殊处理.

9.基于标准化:

你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库&＃xff08;.NET, Ruby, Java,Python, PHP&＃xff09;和多家公司的支持&＃xff08;如&＃xff1a;Firebase,Google, Microsoft&＃xff09;.

四、JWT的Java实现&＃xff1a;

概述&＃xff1a;一个JWT实际上就是一个字符串&＃xff0c;它由三部分组成&＃xff0c;头部、载荷与签名。这里我们只使用简单的载荷&＃xff0c;并将JSON对象进行base64编码得到token

过程&＃xff1a;登录为例子

第一次认证&＃xff1a;第一次登录&＃xff0c;用户从浏览器输入用户名/密码&＃xff0c;提交后到服务器的登录处理的Action层&＃xff08;controller&＃xff09;

Login Action调用认证服务进行用户名密码认证&＃xff0c;如果认证通过&＃xff0c;Login Action层调用用户信息服务获取用户信息&＃xff08;包括完整的用户信息及对应权限信息&＃xff09;&＃xff1b;

返回用户信息后&＃xff0c;Login Action从配置文件再经过工具类处理获取Token签名生成的秘钥信息&＃xff0c;进行Token的生成

生成Token的过程中可以调用第三方的JWT Lib生成签名后的JWT数据&＃xff1b;

完成JWT数据签名后&＃xff0c;将其设置到COOKIE对象中&＃xff0c;并重定向到首页&＃xff0c;完成登录过程&＃xff1b;

请求认证&＃xff1a;

使用&＃xff1a;基于Token的认证机制会在每一次请求中都带上完成签名的Token信息&＃xff0c;这个Token信息可能在COOKIE中&＃xff0c;也可能在HTTP的Authorization头中&＃xff1b;

注意&＃xff1a;

客户端&＃xff08;APP客户端或浏览器&＃xff09;通过GET或POST请求访问资源&＃xff08;页面或调用API&＃xff09;&＃xff1b;

认证服务作为一个Middleware HOOK 对请求进行拦截&＃xff0c;首先在COOKIE中查找Token信息&＃xff0c;如果没有找到&＃xff0c;则在HTTP Authorization Head中查找&＃xff1b;

如果找到Token信息&＃xff0c;则根据配置文件中的签名加密秘钥&＃xff0c;调用JWT Lib对Token信息进行解密和解码&＃xff1b;

完成解码并验证签名通过后&＃xff0c;对Token中的exp、nbf、aud等信息进行验证&＃xff1b;

全部通过后&＃xff0c;根据获取的用户的角色权限信息&＃xff0c;进行对请求的资源的权限逻辑判断&＃xff1b;

如果权限逻辑判断通过则通过Response对象返回&＃xff1b;否则则返回HTTP 401&＃xff1b;

&＃xff08;1&＃xff09;使用JWT的包&＃xff1a;maven导入

io.jsonwebtokenjjwt0.6.0


&＃xff08;2&＃xff09;一个生成token的工具类&＃xff1a;

public class JavaWebToken {private static Logger log &＃61; Logger.getLogger(JavaWebToken.class);private static Key getKeyInstance() {
// return MacProvider.generateKey();//We will sign our JavaWebToken with our ApiKey secretSignatureAlgorithm signatureAlgorithm &＃61; SignatureAlgorithm.HS256;byte[] apiKeySecretBytes &＃61; DatatypeConverter.parseBase64Binary("APP");Key signingKey &＃61; new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());return signingKey;}public static String createJavaWebToken(Map claims) {return Jwts.builder().setClaims(claims).signWith(SignatureAlgorithm.HS256, getKeyInstance()).compact();}public static Map verifyJavaWebToken(String jwt) {try {Map jwtClaims &＃61;Jwts.parser().setSigningKey(getKeyInstance()).parseClaimsJws(jwt).getBody();return jwtClaims;} catch (Exception e) {log.error("json web token verify failed");return null;}}}

&＃xff08;3&＃xff09;一个从request拿去session&＃xff0c;并且解密session得到token得到用户id的类

public class AuthUtil {private static Map getClientLoginInfo(HttpServletRequest request) throws Exception {Map r &＃61; new HashMap<>();String sessionId &＃61; request.getHeader("sessionId");if (sessionId !&＃61; null) {r &＃61; decodeSession(sessionId);return r;}throw new Exception("session解析错误");}public static Long getUserId(HttpServletRequest request) throws Exception {return Long.valueOf((Integer)getClientLoginInfo(request).get("userId"));}/*** session解密*/public static Map decodeSession(String sessionId) {try {return verifyJavaWebToken(sessionId);} catch (Exception e) {System.err.println("");return null;}}
}

使用例子&＃xff1a;

登录的时候把信息放进session&＃xff0c;存到map里&＃xff0c;再交由JWT得到token保存起来

//登录&＃64;RequestMapping(value &＃61; "/login", method &＃61; {RequestMethod.GET, RequestMethod.POST}, produces &＃61; "text/html;charset&＃61;UTF-8")public String login(String account) {User user &＃61; userService.login(account);DTO dto &＃61; new DTO();if (user &＃61;&＃61; null) {dto.code &＃61; "-1";dto.msg &＃61; "Have not registered";} else {//把用户登录信息放进SessionMap loginInfo &＃61; new HashMap<>();loginInfo.put("userId", user.getId());String sessionId &＃61; JavaWebToken.createJavaWebToken(loginInfo);System.out.println("sessionID"&＃43;sessionId);dto.data &＃61; sessionId;}return JSON.toJSONString(dto);}


用户登录以后&＃xff0c;其他的用户性知道的操作就可以使用token进行了&＃xff0c;安全快捷方便&＃xff1a;

//修改昵称&＃64;RequestMapping(value &＃61; "/updateName", method &＃61; {RequestMethod.GET, RequestMethod.POST})public String updateName(HttpServletRequest request, String name) {DTO dto &＃61; new DTO();try {//从session拿到token&＃xff0c;再解密得到useridLong userId &＃61; AuthUtil.getUserId(request);boolean userIsExist &＃61; userService.updateName(userId, name);if (userIsExist &＃61;&＃61; false) {dto.code &＃61; "-1";dto.msg &＃61; "Have not updateAvatar";}} catch (Exception e) {e.printStackTrace();}return JSON.toJSONString(dto);}


这就是token机制的登录认证功能简单实现了&＃xff0c;安全机制等&＃xff0c;以后会有博客补充。

源码下载&＃xff1a;WEB后台–基于Token的WEB后台登录认证机制&＃xff08;并讲解其他认证机制以及COOKIE和session机制&＃xff09;

好了&＃xff0c;WEB后台–基于Token的WEB后台登录认证机制&＃xff08;并讲解其他认证机制以及COOKIE和session机制&＃xff09;讲完了。

本博客是这个系列的第四篇&＃xff0c;讲的是一个简单的登录机制实现。另外&＃xff0c;这个系列还有一些我在外包项目过程中做的优化,虽然核心算法跟安全处理不可以公布&＃xff0c;但我会尽快出完给大家&＃xff0c;分享经验给大家。欢迎在下面指出错误&＃xff0c;共同学习&＃xff01;&＃xff01;你的点赞是对我最好的支持&＃xff01;&＃xff01;

更多内容&＃xff0c;可以访问JackFrost的博客