数字证书实现oauth2.0与token去中心化的解耦

鉴权服务oauth2.0的既要还要的痛点

鉴权服务手撸？不可能，上spring security！
感觉还不够？再叠加oauth2.0！
鉴权太重？换用分布式token！
既然分布式了，是不是可以不用鉴权中心？拖出去三十大板！

一项新的技术解决了一个问题，可能带来新的问题，所以技术栈的选择就不可能有一个最终版本，只有最合适的。
比如说快速开发的小项目，那么直接手写鉴权不来得更快。
需要安全等级高一些的公司稍大项目，那么就换上spring security。
如果未来存在不同系统间的复杂鉴权，那么就需要用到oauth2.0

oauth2.0提供了资源服务校验令牌的插件，实现了资源服务无感验签，但是这是需要付出代价的！这里特指http访问方式，这个方式可能给服务带来延时，如果每个资源服务都需要校验，当调用链路很长的时候，就会造成延迟非常严重。

通用的解决方案

针对http访问延时，也有一个解决的办法，就是传递上下文，然后后面的资源服务跳过验签。不过，还是有存在一个http访问，当并发请求的时候就会出现严重延迟。

不过token的可以选择redis等方式，redis号称支持百万并发，响应是杠杠的。

redis虽然能解决延时，但是实际上把压力给到redis，依旧存在rpc，所以这个时候可能想到jwt，可是jwt就涉及到秘钥安全问题，等于进去下一个死循环了。

数字证书

数字证书最常见就是在https，数字证书就是解决网络信任问题，用在jwt的秘钥安全可信最合适不过。
通过数字证书实现oauth2.0服务负责复杂的鉴权功能，而数字证书负责后续的安全独立的令牌校验。

    @Beanpublic JwtAccessTokenConverter getJwtAccessTokenConverter() throws IOException {JwtAccessTokenConverter jwtAccessTokenConverter = new MyJwtAccessTokenConverter(userDetailService);KeyStoreKeyFactory keyStoreKeyFactory =new KeyStoreKeyFactory(new ClassPathResource("keystore.jks"), "21098jun".toCharArray());KeyPair keyPair = keyStoreKeyFactory.getKeyPair("mykeyalias");jwtAccessTokenConverter.setKeyPair(keyPair);return jwtAccessTokenConverter;}