spring-security-oauth2从v2.4.0.RELEASE开始不推荐使用并迁移

spring-oauth-server最新的版本中使用的spring-security-oauth2版本为v2.3.8.RELEASE;但之后的版本中将不再升级spring-security-oauth2的版本。

这是因为在spring-security-oauth2官方从v2.4.0.RELEASE版本开始将所有类标识为过期的(@Deprecated),并且说明了原因。

* @deprecated See the <a href=”https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide”>OAuth 2.0 Migration Guide</a> for Spring Security 5.

所有类在IDE中显示为不推荐使用。

在查看迁移的文章 https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide 中说明有具体原因。

为此,在spring-oauth-server的最新开发版本中(https://gitee.com/shengzhao/spring-oauth-server/tree/2.1.1/)也将去掉spring security oauth2依赖,改用新的Spring Security提供的 spring-security-authorization-server来替换。

尽请期待。

spring-oauth-server v2.1.0增加token存储的配置说明

spring-oauth-server的v2.1.0版本中增加了新的配置属性:

sos.token.store=jwt

该配置项有两个可选值:jwt或jdbc(默认)

jwt – 表示使用jwt作为token的数据格式,性能更高,推荐使用;配置实现详见 JWTTokenStoreConfiguration.java类;

jdbc – 表示使用数据库存储token的数据(包括refresh token),支持之前版本的实现,也是默认选项,对应的配置实现详见 JdbcTokenStoreConfiguration.java

https://gitee.com/shengzhao/spring-oauth-server

一些阅读中的摘录(202107)

我想了想,为什么草什么都没干就被马牛羊吃了,那草岂不是很可怜?如果区别是在于植物没有生命不会思考,那为什么马牛羊有思考还是不跑走或者是反抗?为什么他们没有形成类似于从奴隶社会到封建社会到社会主义社会的升级?是不是说明其实他们也不会思考?从这个角度看那,他们跟草有什么区别?草存在的意思是不是就是要给更高级的生物提供食物?这么说来,牛羊是不是也是为了支撑很高级的生物去思考和探索世界?
任何事物存在都是有意义的,人进化了思考能力,总结出了文明,然而这种思考跟现实有产生了极大的困惑:每个人生存的意义又是什么?这个问题从来都没有过答案,而生命总是会终止,这么一来,反而衍生了更多的痛苦。
所以,不会思考的生命,就有如蚂蚁那样,未必不是一种幸福。

— 摘至《赵武的自留地》公众号文章“美”

.

“截止2017年年底,公募基金偏股基金年化收益率平均为16.5%,债券基金平均年化收益率为7.2%。公募基金行业累计分红1.71万亿元。为投资者整体创造了很不错的长期价值。”

— 摘至《定投十年,财务自由》

.

投资通常是一个枯燥乏味的计划,是一个近乎机械化的致富过程。

大多数投资者注重个人经验,而不是基础事实或基本利率。也就是说,他们重直觉而轻事实。

大多数投资者偏爱复杂公式,而轻视简单公式。他们似乎有这样一种观念:不复杂不困难的公式不是好公式。

— 摘至 《富爸爸 投资指南》

杂记:一段时间后的记录

比如,看了几本书在2021年,《习惯的力量》不错地将很多的认知的东西给具体地理论化,看了一个月多还未看到末尾页;《带团队》要懂得中国人的处事哲学才能更好地带好一个中国人的团队么;一种疼痛长期的伴随后最近确实感受到了更大的疼痛后开始尝试去缓慢地治疗,CT,理疗等等;

你将工作融入生活,在生活中工作着,快乐着。

对我而言,没有最佳的练习时间,状态好要上,没有状态也要上,只不只是合适就好。没有什么阻挡,你对自由的向往,许巍的《蓝莲花》,始终要发觉脚下的路,追求心中的世界,然后积极,乐观,不用太自信地活着,人就是活一种心态。

借一个为父母完成一个心愿的时机,加上年假的伺候,去进行一段旅行中。

IMG_20210416_155033;天坛

那些过去的逝去的东西真实地存在过?有没有用一种怀疑的态度看待所看到的一切。

Java PublicKey对象与base64格式数据转化

Java中要生成PublicKey需要KeyPair对象,先生成KeyPair,通过KeyPairGenerator,这需要结合算法并设置长度,常用的为RSA,长度可以是 1024,2048等。示例如下:

        KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
keyPairGenerator.initialize(2048);
KeyPair keyPair = keyPairGenerator.generateKeyPair();
assertNotNull(keyPair);

PrivateKey aPrivate = keyPair.getPrivate();
PublicKey aPublic = keyPair.getPublic();

//base64
String base64PrivateKey = new String(Base64.encodeBase64Chunked(aPrivate.getEncoded()));
// System.out.println(base64PrivateKey);
String base64PublicKey = new String(Base64.encodeBase64Chunked(aPublic.getEncoded()));
// System.out.println(base64PublicKey);

使用Base64可将生成的PublicKey,PrivateKey转化为方便传输的 base64格式数据,转化后的PublicKey数据如:

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq7h9NrI7OF4m2R53nemmih4N2ds13n/L
ARfFO1hDGKwE36iU+bCLlkw59gPrWgcsc4lKqVrQC3S3NlBIbkX7pcP2zGth3j5uCfM9DOnM+Jxg XyYVDf9YduuevII142BmG/5CGjrdJmDS4wdUZ+vXJPiSGXMdpRM4+p8jcPoZ71YUPJzxu9pOgD37 RL1UdD3wvM63sixPSmmwTua4GExcKnNZzeiM91UqvI90CG+gH/YG0hf2Pnd5ACquToFLPsUn95d6 cqIERTDi8NiBzB/AhlISM69IDnLhRdU8YjZuxoaFZhQT8eZ6Qhr75/aiUu0zN3aNeOHnrJHKV/Lq
xng6VQIDAQAB

当需要使用时可通过 KeyFactory 将base64数据转化为具体的PublicKey或PrivateKey对象。代码如下:

KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(Base64.decodeBase64(base64PrivateKey));
PrivateKey privateKey = keyFactory.generatePrivate(keySpec);
assertNotNull(privateKey);
assertEquals(privateKey, aPrivate);


PublicKey publicKey = keyFactory.generatePublic(new X509EncodedKeySpec(Base64.decodeBase64(base64PublicKey)));
assertNotNull(publicKey);
assertEquals(publicKey, aPublic);

转化后的对象与原生的是一样的,可用于加密/解密, 签名验签等。

代码链接:https://gitee.com/mkk/MyOIDC/blob/b14bb9ef6da6ca6235b2f705cbd713fbe97f6436/myoidc-server/src/test/java/myoidc/server/service/business/RSAPublicKeyTest.java

专利:2016102613273 单点登录技术中的主令牌获取方法、单点登录方法及系统

技术专利:2016102613273 单点登录技术中的主令牌获取方法、单点登录方法及系统。

摘要 本发明提供的单点登录技术中的主令牌获取方法,涉及互联网领域,该方法通过手机端首先要通过识别码下发服务器的验证来换取识别码,之后在期望获取主令牌的时候,使用手机端将该识别码发送给令牌颁发服务器,之后令牌颁发服务器将该识别码提供给识别码下发服务器进行验证,只有该次验证通过后,令牌颁发服务器才会将对应的主令牌提供给手机端,这样,即使外部设备知悉了账户和密码,由于外部设备无法通过识别码下发服务器的验证,导致其依旧无法获取主令牌,保证了主令牌下发的安全性,也就保证了单点登录整体的安全性。

http://epub.cnipa.gov.cn/certifdesc.action?strWhere=CN105959267B

OAuth 2.1的状态与主要特征

经过多年的OAuth 2.0协议的发展,最新版本的 OAuth 2.1 协议已经在进行中,可访问 https://oauth.net/2.1/ 获取最新的相关信息。

2.1版本相比2.0版本的优化或不同点有:

OAuth 2.1

简单点说就是:

  • PKCE变成必须的了
  • Redrect URI的检查更严格
  • grant_type中的password, implicit都不再推荐使用(甚至不再支持)
  • 不再允许通过URL查询参数传递access_token(甚至不再支持)
  • 刷新token增加约束限制(如一次性刷新)

OAuth2.1将变得更加安全,从流程定义与各个端(endpoint)来讲;这也符合网络环境越来越复杂,安全问题越来越高的实际场景。相比传统的client端浏览器与APP来讲,未来的client端会更多样,如智能家居设备,穿戴设备,工业互联设备等。

从另一个方面来说,认证凭证(如常见的 密码)将趋于在授权服务(Authorization Server)中统一进行管理,认证的操作收归到授权服务器端来管控,不再放由client端可知晓(想想grant_type=password中可通过API传递用户凭证是多么的信任client端啊)。