什么是SSO
在企业发展初期,企业使用的系统很少,通常一个或者两个,每个系统都有自己的登录模块,运营人员每天用自己的账号登录,很方便。但随着企业的发展,用到的系统随之增多,运营人员在操作不同的系统时,需要多次登录,而且每个系统的账号都不一样,这对于运营人员来说,很不方便。于是,就想到是不是可以在一个系统登录,其他系统就不用登录了呢?这就是单点登录要解决的问题。单点登录英文全称Single Sign On,简称就是SSO。它的解释是:在多个应用系统中,只需要登录一次,就可以访问其他相互信任的应用系统。
普通认证机制
如上图所示,我们在浏览器(Browser)中访问一个应用,这个应用需要登录,我们填写完用户名和密码后,完成登录认证。这时,我们在这个用户的session中标记登录状态为yes(已登录),同时在浏览器(Browser)中写入Cookie,这个Cookie是这个用户的唯一标识。下次我们再访问这个应用的时候,请求中会带上这个Cookie,服务端会根据这个Cookie找到对应的session,通过session来判断这个用户是否登录。如果不做特殊配置,这个Cookie的名字叫做jsessionid,值在服务端(server)是唯一的。
同域名下的SSO
一个企业一般情况下只有一个域名,通过二级域名区分不同的系统。比如我们有个域名叫做:a.com,同时有两个业务系统分别为:app1.a.com和app2.a.com。我们要做单点登录(SSO),需要一个登录系统,叫做:sso.a.com。
我们只要在sso.a.com登录,app1.a.com和app2.a.com就也登录了。通过上面的登陆认证机制,我们可以知道,在sso.a.com中登录了,其实是在sso.a.com的服务端的session中记录了登录状态,同时在浏览器端(Browser)的sso.a.com下写入了Cookie。那么我们怎么才能让app1.a.com和app2.a.com登录呢?这里有两个问题:
Cookie是不能跨域的,我们Cookie的domain属性是sso.a.com,在给app1.a.com和app2.a.com发送请求是带不上的。
sso、app1和app2是不同的应用,它们的session存在自己的应用内,是不共享的
那么我们如何解决这两个问题呢?
针对第一个问题,sso登录以后,可以将Cookie的域设置为顶域,
即.a.com,这样所有子域的系统都可以访问到顶域的Cookie。我们在设置Cookie时,只能设置顶域和自己的域,不能设置其他的域。比如:我们不能在自己的系统中给baidu.com的域设置Cookie。Cookie的问题解决了,我们再来看看session的问题。我们在sso系统登录了,这时再访问app1,Cookie也带到了app1的服务端(Server),app1的服务端怎么找到这个Cookie对应的Session呢?这里就要把3个系统的Session共享,如图所示。共享Session的解决方案有很多,例如:SpringSession。这样第2个问题也解决了。
JWT
什么是JWT
JSON Web Token(JWT)是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。
JWT的构成
一个JWT实际上就是一个字符串,它由三部分组成,头部、载荷与签名。
头部(Header)
头部用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。
{“typ”:“JWT”,“alg”:“HS256”}
在头部指明了签名算法是HS256算法。 我们进行BASE64编码http://base64.xpcha.com/,编码后的字符串如下:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
小知识:Base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于2的6次方等于
64,所以每6个比特为一个单元,对应某个可打印字符。三个字节有24个比特,对应于4个
Base64单元,即3个字节需要用4个可打印字符来表示。JDK 中提供了非常方便
的 BASE64Encoder 和 BASE64Decoder,用它们可以非常方便的完成基于 BASE64 的编码和解码
载荷(payload)
载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分
(1)标准中注册的声明(建议但不强制使用)
iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间,这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前,该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。
(2)公共的声明
公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.
(3)私有的声明
私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为明文信息。
这个指的就是自定义的claim。比如下面面结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于:JWT规定的claim,JWT的接收方在拿到JWT之后,都知道怎么对这些标准的claim进行验证(还不知道是否能够验证);而private claims不会验证,除非明确告诉接收方要对这些claim进行验证以及规则才行。
定义一个payload:
{“sub”:“1234567890”,“name”:“John Doe”,“admin”:true}
然后将其进行base64加密,得到Jwt的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
签证(signature)
jwt的第三部分是一个签证信息,这个签证信息由三部分组成:
header (base64后的)
payload (base64后的)
secret
这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串,然后通过header中声明的加密方式进行加盐secret组合加密,然后就构成了jwt的第三部分。
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
将这三部分用.连接成一个完整的字符串,构成了最终的jwt:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
注意:secret是保存在服务器端的,jwt的签发生成也是在服务器端的,secret就是用来进行jwt的签发和jwt的验证,所以,它就是你服务端的私钥,在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
签名的作用:保证 JWT 没有被篡改过,原理如下:
HMAC 算法是不可逆算法,类似 MD5 和 hash ,但多一个密钥,密钥(即上面的 secret)由服务端持有,客户端把 token 发给服务端后,服务端可以把其中的头部和载荷再加上事先共享的 secret 再进行一次 HMAC 加密,得到的结果和 token 的第三段进行对比,如果一样则表明数据没有被篡改。
JJWT的介绍和使用
JJWT是一个提供端到端的JWT创建和验证的Java库。永远免费和开源(Apache License,版本2.0),JJWT很容易使用和理解。它被设计成一个以建筑为中心的流畅界面,隐藏了它的大部分复杂性。
创建TOKEN
(1)依赖引入
在项目中的pom.xml中添加依赖:
<!--鉴权-->
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.0</version>
</dependency>
(2)创建测试
在的/test/java下创建测试类,并设置测试方法
public class JwtTest {
/****
* 创建Jwt令牌
*/
@Test
public void testCreateJwt(){
JwtBuilder builder= Jwts.builder()
.setId("888") //设置唯一编号
.setSubject("小白") //设置主题 可以是JSON数据
.setIssuedAt(new Date()) //设置签发日期
.signWith(SignatureAlgorithm.HS256,"kaikeba");//设置签名 使用HS256
算法,并设置SecretKey(字符串)
//构建 并返回一个字符串
System.out.println( builder.compact() );
}
}
运行打印结果:
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiLllK_kuIDnmoTmoIfor4YiLCJpc3MiOiLpooHlj5HogIUiLCJ
zdWIiOiLkuLvpopgiLCJleHAiOjE2MDIzMjIwMDEsIm15Y2l0eSI6ImJlaWppbmciLCJteWFkZHJlc3M
iOiJjbiJ9.c7UxJaQVxulwVqvIZLP_8RxSTbKOyixcU6mgMFaYrw0
再次运行,会发现每次运行的结果是不一样的,因为我们的载荷中包含了时间。
TOKEN解析
我们刚才已经创建了token ,在web应用中这个操作是由服务端进行然后发给客户端,客户端在下次向服务端发送请求时需要携带这个token(这就好像是拿着一张门票一样),那服务端接到这个token 应该解析出token中的信息(例如用户id),根据这些信息查询数据库返回相应的结果。
/***
* 解析Jwt令牌数据
*/
@Test
public void testParseJwt(){
String
compactJwt="eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiLllK_kuIDnmoTmoIfor4YiLCJpc3MiOiLpooH
lj5HogIUiLCJzdWIiOiLkuLvpopgiLCJleHAiOjE2MDIzMjIwMDEsIm15Y2l0eSI6ImJlaWppbmciLCJ
teWFkZHJlc3MiOiJjbiJ9.c7UxJaQVxulwVqvIZLP_8RxSTbKOyixcU6mgMFaYrw0";
Claims claims = Jwts.parser().
setSigningKey("kaikeba").
parseClaimsJws(compactJwt).
getBody();
System.out.println(claims);
}
运行打印效果:
{jti=888, sub=小白, iat=1562062287}
试着将token或签名秘钥篡改一下,会发现运行时就会报错,所以解析token也就是验证token.
设置过期时间
有很多时候,我们并不希望签发的token是永久生效的,所以我们可以为token添加一个过期时间。
token过期设置
.setExpiration(date)//用于设置过期时间 ,参数为Date类型数据
运行打印效果如下:
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiI4ODgiLCJzdWIiOiLlsI_nmb0iLCJpYXQiOjE1NjIwNjI5MjU
sImV4cCI6MTU2MjA2MjkyNX0._vs4METaPkCza52LuN0-2NGGWIIO7v51xt40DHY1U1Q
解析token:
/***
* 解析Jwt令牌数据
*/
@Test
public void testParseJwt(){
String
compactJwt="eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiI4ODgiLCJzdWIiOiLlsI_nmb0iLCJpYXQiOjE
1NjIwNjI5MjUsImV4cCI6MTU2MjA2MjkyNX0._vs4METaPkCza52LuN0-
2NGGWIIO7v51xt40DHY1U1Q";
Claims claims = Jwts.parser().
setSigningKey("lxs").
parseClaimsJws(compactJwt).
getBody();
System.out.println(claims);
}
打印结果:
自定义claims
我们刚才的例子只是存储了id和subject两个信息,如果你想存储更多的信息(例如角色)可以定义自定义claims。
创建测试类,并设置测试方法:
创建token:
运行打印:
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiLllK_kuIDnmoTmoIfor4YiLCJpc3MiOiLpooHlj5HogIUiLCJ
zdWIiOiLkuLvpopgiLCJleHAiOjE2MDIzMjIwMDEsIm15Y2l0eSI6ImJlaWppbmciLCJteWFkZHJlc3M
iOiJjbiJ9.c7UxJaQVxulwVqvIZLP_8RxSTbKOyixcU6mgMFaYrw0
解析TOKEN:
/***
* 解析Jwt令牌数据
*/
@Test
public void testParseJwt(){
String
compactJwt="eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiLllK_kuIDnmoTmoIfor4YiLCJpc3MiOiLpooH
lj5HogIUiLCJzdWIiOiLkuLvpopgiLCJleHAiOjE2MDIzMjIwMDEsIm15Y2l0eSI6ImJlaWppbmciLCJ
teWFkZHJlc3MiOiJjbiJ9.c7UxJaQVxulwVqvIZLP_8RxSTbKOyixcU6mgMFaYrw0";
Claims claims = Jwts.parser().
setSigningKey("itcast").
parseClaimsJws(compactJwt).
getBody();
System.out.println(claims);
}
运行效果:
上述代码:
package com.lxs.cloud;
import io.jsonwebtoken.Claims;
import io.jsonwebtoken.JwtBuilder;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import org.junit.Test;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;
public class TestJWT {
@Test
public void createJWT() {
long l1 = System.currentTimeMillis(); //当前时间戳
long l2 = l1 + 20000; //过期时间错
JwtBuilder builder = Jwts.builder()
.setId("12356") //设置唯一编号
.setSubject("password123") //主题
.setIssuedAt(new Date()) //签发时间
// .setExpiration(new Date(l2))
.claim("role", "ADMIN")
.signWith(SignatureAlgorithm.HS256, "kaikeba"); //签名,采用HS256算法加密,秘钥
//自定义载荷
Map<String, Object> map = new HashMap<>();
map.put("myaddress", "cn");
map.put("mycity", "hangzhou");
builder.addClaims(map);
System.out.println(builder.compact());
}
@Test
public void testParseJwt() {
String jwt = "eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxMjM1NiIsInN1YiI6InBhc3N3b3JkMTIzIiwiaWF0IjoxNjA1NzY4NzQ4LCJyb2xlIjoiQURNSU4iLCJteWNpdHkiOiJoYW5nemhvdSIsIm15YWRkcmVzcyI6ImNuIn0.598OCjR-ItxRat7_VvWklUbIgGehJuEcXu21EEub8vs";
Claims claims = Jwts.parser()
.setSigningKey("kaikeba")
.parseClaimsJws(jwt)
.getBody();
System.out.println(claims);
//这个可以输出自定义的载荷字段
System.out.println(claims.get("role"));
System.out.println(claims.getSubject());
}
}
JWT工具 加密 解密的过程(完整代码):
public class JwtUtil {
//有效期为
public static final Long JWT_TTL = 3600000L;// 60 * 60 *1000 一个小时
//Jwt令牌信息
public static final String JWT_KEY = "kaikeba";
/**
* 生成令牌
* @param id
* @param subject
* @param ttlMillis
* @return
*/
public static String createJWT(String id, String subject, Long ttlMillis) {
//指定算法
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
//当前系统时间
long nowMillis = System.currentTimeMillis();
//令牌签发时间
Date now = new Date(nowMillis);
//如果令牌有效期为null,则默认设置有效期1小时
if (ttlMillis == null) {
ttlMillis = JwtUtil.JWT_TTL;
}
//令牌过期时间设置
long expMillis = nowMillis + ttlMillis;
Date expDate = new Date(expMillis);
//生成秘钥
SecretKey secretKey = generalKey();
//封装Jwt令牌信息
JwtBuilder builder = Jwts.builder()
.setId(id) //唯一的ID
.setSubject(subject) // 主题 可以是JSON数据
.setIssuer("admin") // 签发者
.setIssuedAt(now) // 签发时间
.signWith(signatureAlgorithm, secretKey) // 签名算法以及密匙
.setExpiration(expDate); // 设置过期时间
return builder.compact();
}
/**
* 生成加密 secretKey
*使用AES算法生成秘钥
* @return
*/
public static SecretKey generalKey() {
byte[] encodedKey = Base64.getEncoder().encode(JwtUtil.JWT_KEY.getBytes());
SecretKey key = new SecretKeySpec(encodedKey, 0, encodedKey.length, "AES");
return key;
}
/**
* 解析令牌数据
*
* @param jwt
* @return
* @throws Exception
*/
public static Claims parseJWT(String jwt) throws Exception {
SecretKey secretKey = generalKey();
return Jwts.parser()
.setSigningKey(secretKey)
.parseClaimsJws(jwt)
.getBody();
}
public static void main(String[] args) {
String jwt = JwtUtil.createJWT("weiyibiaoshi", "aaaaaa", null);
System.out.println(jwt);
try {
Claims claims = JwtUtil.parseJWT(jwt);
System.out.println(claims);
} catch (Exception e) {
e.printStackTrace();
}
}
}
什么是 OAuth 2
OAuth 是一个开放标准,该标准允许用户让第三方应用访问该用户在某一网站上存储的私密资源(如头像、照片、视频等),而在这个过程中无须将用户名和密码提供给第三方应用。实现这一功能是通过提供一个令牌(token),而不是用户名和密码来访问他们存放在特定服务提供者的数据。
每一个令牌授权一个特定的网站在特定的时段内访问特定的资源。这样,OAuth 让用户可以授权第三方网站灵活地访问存储在另外一些资源服务器的特定信息,而非所有内容。目前主流的 qq,微信等第三方授权登录方式都是基于 OAuth2 实现的。
OAuth 2 是 OAuth 协议的下一版本,但不向下兼容 OAuth 1.0。OAuth 2 关注客户端开发者的简易性,同时为 Web 应用、桌面应用、移动设备、起居室设备提供专门的认证流程。
传统的 Web 开发登录认证一般都是基于 Session 的,但是在前后端分离的架构中继续使用Session 会有许多不便,因为移动端(Android、iOS、微信小程序等)要么不支持Cookie(微信小程序),要么使用非常不便,对于这些问题,使用 OAuth 2 认证都能解决。
OAuth 2 授权流程
步骤1:客户端(第三方应用)向用户请求授权。
步骤2:用户单击客户端所呈现的服务授权页面上的同意授权按钮后,服务端返回一个授权许可凭证给客户端。
步骤3:客户端拿着授权许可凭证去授权服务器申请令牌。
步骤4:授权服务器验证信息无误后,发放令牌给客户端。
步骤5:客户端拿着令牌去资源服务器访问资源。
步骤6:资源服务器验证令牌无误后开放资源。
OAuth 2 角色
资源所有者(Resource Owner):即代表授权客户端访问本身资源信息的用户,客户端访问用户帐户
的权限仅限于用户授权的“范围”。
客户端(Client):即代表意图访问受限资源的第三方应用。在访问实现之前,它必须先经过用户者授
权,并且获得的授权凭证将进一步由授权服务器进行验证。
授权服务器(Authorization Server):授权服务器用来验证用户提供的信息是否正确,并返回一个
令牌给第三方应用。
资源服务器(Resource Server):资源服务器是提供给用户资源的服务器,例如头像、照片、视频
等。
OAuth 2 授权模式
OAuth 协议的授权模式共分为 4 种,分别说明如下:
授权码模式授权码模式(authorization code)是功能最完整、流程最严谨的授权模式。它的特点就是通过客户端的服务器与授权服务器进行交互,国内常见的第三方平台登录功能基本 都是使用这种模式。
简化模式简化模式不需要客户端服务器参与,直接在浏览器中向授权服务器中请令牌,一般若网站是纯静态页面,则可以采用这种方式。
密码模式密码模式是用户把用户名密码直接告诉客户端,客户端使用这些信息向授权服务器中请令牌。这需要用户对客户端高度信任,例如客户端应用和服务提供商是同一家公司。
客户端模式客户端模式是指客户端使用自己的名义而不是用户的名义向服务提供者申请授权。严格来说,客户端模式并不能算作 OAuth 协议要解决的问题的一种解决方案,但是,对于开发者而言,在一些前后端分离应用或者为移动端提供的认证授权服务器上使用这种模式还是非常方便的。
1 授权码模式
授权码(authorization code)方式,指的是第三方应用先申请一个授权码,然后再用该码获取令牌
1。授权码模式功能最完整、使用最广泛、流程最严密的授权模式
第三方授权一般就是授权码模式,流程如下:
(A):客户端携带client_id、redirect_uri,中间通过代理者访问授权服务器,如果已经登录过会直接返回redirect_uri,没有登录过就跳转到登录页面
(B)授权服务器对客户端进行身份验证(通过用户代理,让用户输入用户名和密码)
(C)授权通过,会重定向到redirect_uri并携带授权码code作为uri参数
(D)客户端携带授权码访问授权服务器
(E)验证授权码通过,返回acceptToken
最后拿上令牌去访问资源服务器
2 简化模式
简化模式(implicit grant type)不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了"授权码"这个步骤,因此称简化模式。简化模式是相对于授权码模式而言的 (浏览器持有令牌)
简化模式,流程如下:
(A):客户端携带client_id、redirect_uri,中间通过代理者访问授权服务器,如果已经登录过会直接返回redirect_uri,没有登录过就跳转到登录页面
(B)授权服务器对客户端进行身份验证(通过用户代理,让用户输入用户名和密码)
(C)授权通过,会重定向到redirect_uri并携带授权码token作为uri参数
(D)客户端携带授权码访问资源服务器
(E)验证token通过,返回资源
3 密码模式
密码模式(resource owner password credentials):密码模式中,用户向客户端提供自己的用户名和密码,这通常用在用户对客户端高度信任的情况
密码授权一般就是授权码模式,流程如下:
(A)用户访问客户端,提供URI连接包含用户名和密码信息给授权服务器
(B)授权服务器对客户端进行身份验证
(C)授权通过,返回acceptToken给客户端
4 客户端模式
客户端模式(client credentials):客户端模式(client credentials)适用于没有前端的命令行应用,即在命令行下请求令牌
客户端把 client id 和 password直接发给服务器,服务器返回token,客户端把直接拿着token访问
令牌存储方式
对于token存储有如下方式,分别进行介绍:
InMemoryTokenStore,默认存储,保存在内存
JdbcTokenStore,access_token存储在数据库
JwtTokenStore,JWT这种方式比较特殊,这是一种无状态方式的存储,不进行内存、数据库存储,只是JWT中携带全面的用户信息,保存在jwt中携带过去校验就可以,系统中采用JwtTokenStore
RedisTokenStore,将 access_token 存到 redis 中。
JwkTokenStore,将 access_token 保存到 JSON Web Key。