应用场景
spring Security OAuth2有一个奇葩的设计,那就是它将与access_token 相关的所有属于都封装到OAuth2AccessToken 中,然后保存时会直接将该对象序列化成字节写入数据库。我们在资源服务器中想要直接读数据库来取出access_token 来验证令牌的有效性,然而又不想引入Spring Security的相关依赖污染jar包。这时可以将Spring Security中OAuth2AccessToken 的唯一实现类DefaultOAuth2AccessToken 的源码copy到我们的项目中,然后通过JDBC读取byte[] , 通过JDK自带的反序列化机制来还原DefaultOAuth2AccessToken 对象。这时就会遇到问题,即原来的OAuth2AccessToken 所在包是以org.springframework.security 开头的,而我们copy过来源码后,包名是以我们自己定义的包cn.com.XXXX 开头的,这样在反序列化时,即使两个类的字段完全一样,但由于字节流中存储的类信息的全限定性名不同,也会导致反序列化失败。
解决方案
我们可以定义子类继承JDK的ObjectInputStream ,然后重写readClassDescriptor() 方法:
@Override
这样在反序列化时就不会报错了。原理并不复杂,其实就是在解析字节流时,将解析后应为org.springframework.security.oauth2.common.DefautOAuthToken 的class ,替换成了我们自己copy过来源码的cn.com.XXXXXX.DefaultOAuthToken 从而达到”欺骗”的目的。在该场景下,我们就可以做到在资源提供方不引入 Spring Security 框架而只使用Spring Security OAuth2的授权服务。资源提供方直接读数据库来验证令牌的有效性,而不是向授权服务查询。
|