前言
一、单点登录是什么?
二、单点登录的实现方式
1.Cookie方案:
2.Session方案:
3.Token方案:
三、JWT是什么
1.JWT的概况
2.JWT的组成
3.JWT的用法
4.JWT优缺点
四、Token实现单点登录(代码)
1.添加JWT依赖与JWT工具类
2.编写登录方法
总结
在分布式项目架构中,为了提高用户体验性,用户只需要认证一次便可以在多个拥有访问权限的系统中访问,这个功能叫做单点登录(SSO)。现在市面上大多采用OAuth2.0实现单点登录,次方案下需要另准备一个统一认证中心系统。此文章只是SSO简单实现,所以没用OAuth2.0。想了解OAuth2.0相关内容,请看下一篇文章。
单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统(例如淘宝、天猫之间的关系)。简而言之,多个系统,统一登陆。
单点登录主要强调的是登录以后,各个系统间数据共享问题。
单点登录的实现方案,一般就包含:Cookie、Session、Token
流程:
用cookie作为媒介存放用户凭证。 用户登录系统之后,会返回一个加密的cookie,当用户访问子应用的时候会带上这个cookie,授权以解密cookie并进行校验,校验通过后即可登录当前用户。
缺点:
(1)Cookie不安全:攻击者可以通过伪造Cookie伪造成特定用户身份,可以用加密规避(前提是加密算法不被泄露)。
(2)不能跨域实现免登:Cookie一般是以域名为分割的。如:baidu.com 无法读到 cnblogs.com 写的 cookie。域名是可以访问上级域名的Cookie的。 即a.baidu.com是可以访问baidu.com下的Cookie的。(一级域名相同,只是二级或更高级域名不同的站点,如:a.baidu.com、b.baidu.com可以通过设置 domain 参数共享 cookie 读写。)
补充:域名通过 “.” 号切分后,从右往左看,不包含 “.” 的是顶级域名,包含一个 “.”的是一级域名,如:baidu.com, 包含两个“.”的是二级域名,如:a. baidu.com ,以此类推。
流程:
因为是分布式的系统,多服务器是不共享session,传统的单机session不适用于分布式系统中,所以这里使用分布式session。session属于有状态,实现分布式session有四种方案(session复制、客户端存储、HASH一致性、统一存储)。详情请看:分布式session解决方案_半格咖啡的博客-CSDN博客
流程运行:
(1) 用户第一次登录时,将会话信息(用户Id和用户信息),比如以用户Id为Key,写入分布式Session;
(2) 用户再次登录时,获取分布式Session,是否有会话信息,如果没有则调到登录页;
(3) 一般采用Cache中间件实现,建议使用Redis,因此它有持久化功能,方便分布式Session宕机后,可以从持久化存储中加载会话信息;
(4) 存入会话时,可以设置会话保持的时间,比如15分钟,超过后自动超时;
缺点:
(1)服务器压力增大:通常session是存储在内存中的,每个用户通过认证之后都会将session数据保存在服务器的内存中,而当用户量增大时,服务器的压力增大。(可以将数据保存在磁盘中)
(2)扩展性不强:如果将来搭建了多个服务器,虽然每个服务器都执行的是同样的业务逻辑,但是session数据是保存在内存中的(不是共享的),用户第一次访问的是服务器1,当用户再次请求时可能访问的是另外一台服务器2,服务器2获取不到session信息,就判定用户没有登陆过。(可以使用分布式session将session在各个集群中保持一致)
(3)CSRF跨站伪造请求攻击:session是基于cookie进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。
流程:
现如今Token方案登录认证大多采用OAuth2.0方案,这里只是简单实现sso效果,所以没实现OAuth2.0流程。
缺点:
(1)占用带宽
(2)无法在服务器端销毁(token生成后就返回给了客户端,服务器端无法进行删除)
注:基于微服务开发,选择token的形式相对较多,因此我之后会使用token实现sso
通俗讲:就是一种生存字符串的规则叫JWT。JWT是JSON WEB TOKEN的缩写,它是基于 RFC 7519 标准定义的一种可以安全传输的的JSON对象,由于使用了数字签名,所以是可信任和安全的。
Token(令牌)属于无状态,因每个人制定的规则不同,生成的结果也不同。目前,多数人采用JWT为统一令牌标准,之后我也采用JWT作为token生成标准。
jwt实例可以在该网站上获得解析结果:JSON Web Tokens - jwt.io
组成:
该对象为一个很长的字符串,字符之间通过"."分隔符分为三个子串。
每一个子串表示了一个功能块,总共有以下三个部分:JWT头、有效载荷和签名
JWT头:
JWT头部分是一个描述JWT元数据的JSON对象,通常如下所示。
{ "alg": "HS256", "typ": "JWT" }
在上面的代码中,
alg属性表示签名使用的算法,默认为HMAC SHA256(写为HS256);
typ属性表示令牌的类型,JWT令牌统一写为JWT。
最后,使用Base64 URL算法将上述JSON对象转换为字符串保存。
有效载荷【用户信息】:
(通俗的讲就是用户信息)有效载荷部分,是JWT的主体内容部分,也是一个JSON对象,包含需要传递的数据。 JWT指定七个默认字段供选择
iss:发行人 exp:到期时间 sub:主题 aud:用户 nbf:在此之前不可用 iat:发布时间 jti:JWT ID用于标识该JWT
除以上默认字段外,我们还可以自定义私有字段,如下例:
{ "sub": "1234567890", "name": "Helen", "admin": true }
请注意,默认情况下JWT是未加密的,任何人都可以解读其内容,因此不要构建隐私信息字段,存放保密信息,以防止信息泄露。
JSON对象也使用Base64 URL算法转换为字符串保存。
签名哈希【防伪标志】:
签名哈希部分是对上面两部分数据签名,通过指定的算法生成哈希,以确保数据不会被篡改。
首先,需要指定一个密码(secret)。该密码仅仅为保存在服务器中,并且不能向用户公开。然后,使用标头中指定的签名算法(默认情况下为HMAC SHA256)根据以下公式生成签名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)
在计算出签名哈希后,JWT头,有效载荷和签名哈希的三个部分组合成一个字符串,每个部分用"."分隔,就构成整个JWT对象。
Base64URL算法:
如前所述,JWT头和有效载荷序列化的算法都用到了Base64URL。该算法和常见Base64算法类似,稍有差别。 作为令牌的JWT可以放在URL中(例如api.example/?token=xxx)。 Base64中用的三个字符是"+","/“和”=",由于在URL中有特殊含义,因此Base64URL中对他们做了替换:"=“去掉,”+“用”-“替换,”/“用”_"替换,这就是Base64URL算法。
客户端接收服务器返回的JWT,将其存储在Cookie或localStorage中。
此后,客户端将在与服务器交互中都会带JWT。如果将它存储在Cookie中,就可以自动发送,但是不会跨域,因此一般是将它放入HTTP请求的Header Authorization字段中。当跨域时,也可以将JWT被放置于POST请求的数据主体中。
依赖:
io.jsonwebtoken jjwt0.9.1
工具类:
public class JwtUtils { //token过期时间 public static final long EXPIRE = 1000 * 60 * 60 * 24; //秘钥,每个公司生成规则不一样 public static final String APP_SECRET = "rikka六花"; //生成token字符串方法,参数根据自己实际要求指定 public static String getJwtToken(String id, String nickname) { String JwtToken = Jwts.builder() //设置jwt头信息,红色部分,内容固定,不需要改 .setHeaderParam("typ", "JWT") .setHeaderParam("alg", "HS256") .setSubject("guli-user")//设置主题(可选) .setIssuedAt(new Date())//设置发布时间(可选) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE))//设置过期时间 //设置token主体部分,存储用户信息,可设置多个值 .claim("id", id) .claim("nickname", nickname) //设置签名哈希(防伪标志) .signWith(SignatureAlgorithm.HS256, APP_SECRET) .compact(); return JwtToken; } /** * 判断token是否存在与有效 * * @param jwtToken * @return */ public static boolean checkToken(String jwtToken) { if (StringUtils.isEmpty(jwtToken)) return false; try { //根据设置的防伪码解析token Jwts.parser().setSigningKey(APP_SECRET).parseClaimsJws(jwtToken); } catch (Exception e) { e.printStackTrace(); return false; } return true; } /** * 判断token是否存在与有效 * * @param request * @return */ public static boolean checkToken(HttpServletRequest request) { try { String jwtToken = request.getHeader("token"); if (StringUtils.isEmpty(jwtToken)) return false; //根据设置的防伪码解析token Jwts.parser().setSigningKey(APP_SECRET).parseClaimsJws(jwtToken); } catch (Exception e) { e.printStackTrace(); return false; } return true; } /** * 根据token获取id * * @param request * @return */ public static String getMemberIdByJwtToken(HttpServletRequest request) { String jwtToken = request.getHeader("token"); if (StringUtils.isEmpty(jwtToken)) return ""; //根据设置的防伪码解析token,获取对象 JwsclaimsJws = Jwts.parser().setSigningKey(APP_SECRET).parseClaimsJws(jwtToken); //获取token有效载荷【用户信息】 Claims claims = claimsJws.getBody(); return (String) claims.get("id"); } }
@Override public String login(LoginVo loginVo) { //写你自己的具体登录逻辑: //1.判断参数是否为空 ... //2.判断数据库是否存在该用户 ... //3.判断加密后的密码参数和数据库是否一致 ... //4.判断用户是否禁用 ... //5.生成jwt令牌返回给前端 return JwtUtils.getJwtToken(ucenterMember.getId(), ucenterMember.getNickname()); }
将JWT返回给前端,前端选择将令牌存入cookie或放进地址栏。之后每次都带着JWT发送请求,因为JWT有效载荷里存有id,所以下次后端可根据id查找对应用户信息返回。可根据是否有token判断是否登录,所以单点登录就实现了。
单点登录在我看来是强调登录之后,下次请求是否有token,并根据token实现数据共享的问题。完整流程应该是:结合security和oauth2.0,先由security拦截请求解析token。如果token合法,便继续代码流程;若违法,便跳转到登录页面进行登录,登录请求发送到统一授权中心进行校验然后颁发令牌,根据令牌实现了单点登录或请求详细信息。
以上就是个人对单点登录的理解,关于结合security和oauth2.0的做法我会在之后的文章写出。因为大多是自己理解,可能有不少错误的地方。欢迎大家在评论区指正。