看下源码修下 SpringSecurityOAuth2 的bug,解决令牌检查端点未实现 OAuth2 规范带来的坑: Resour...

栏目: IT技术 · 发布时间: 4年前

内容简介:最近在自己搭一个使用目的是为了在网关层做所有的鉴权操作。  其实一切都还好,ajax 登陆、OAuth2密码模式的 token 获取、token刷新等 都有序进行中。认证的整个流程都没发现问题,可是一到鉴权的阶段就不对劲了。

最近在自己搭一个使用 SpringSecutiryOAuth2 的认证服务器, 这里的接口基于 SpringMVC, 而资源服务器是 SpringCloudGateway 建立的网关层,实现是 WebFlux。

目的是为了在网关层做所有的鉴权操作。  其实一切都还好,ajax 登陆、OAuth2密码模式的 token 获取、token刷新等 都有序进行中。

认证的整个流程都没发现问题,可是一到鉴权的阶段就不对劲了。

主要就是令牌内省失败,正常的令牌没问题,但是令牌如果一过期/或者是错误的令牌, 直接就报错了。这我就觉得很不对劲。

问题是我想了想 无论是 AuthorizationServer 还是 ResourceServer , 我都没有对具体认证流程作出改动。 仅仅实现了 SpringSecurity 提供的拓展点。比如 Token存储、Client存储、token 的附加信息、权限查询 之类的。

那这就不应该啊?? 我这用的你默认的实现,怎么还能有问题呢?

而又由于网关层 也就是OAuth2 ResourceServer 他是一个 WebFlux 搭建的web服务,  这个东西调试是真的不好调,里面大量的 lambda 和异步看的我头都要炸了。

不过又还能怎么办呢? ResourceServer/ AuthorizationServer 源码看看看看他丫的。 Debug日志开他丫的。

可是看他这个 WebFlux 下的鉴权源码真的很痛苦。 所以我具体详细的 Debug 流程就不细说了。

ResourceServer introspect

首先就是看 ResourceServer 的令牌内省(introspect)  也就是检查令牌的机制流程

具体触发时机为: 一个客户端试图来请求 ResourceServer 受保护的资源时、若是携带了 Authorization 请求头( Bearer ) 时则会触发令牌内省

最终我找到了处理token 鉴权具体类,就是它: NimbusReactiveOpaqueTokenIntrospector

这里贴一段 WebFlux 作为资源服务器处理 token 鉴权的流程源码。

Gateway的过滤器会提取出 Bearer Token 然后调用此方法。每个流程都写了注释, 还是很清晰的。

@Override
public Mono<OAuth2AuthenticatedPrincipal> introspect(String token) {
 
    return Mono.just(token)
            .flatMap(this::makeRequest)//携带token请求 AuthorizationServer
            .flatMap(this::adaptToNimbusResponse)//检查Http响应正确性 (看是不是200)
            .map(this::parseNimbusResponse)//封装Http响应为Token内省响应
            .map(this::castToNimbusSuccess)//检查Token内省响应正确性
            .doOnNext(response -> validate(token, response))//效验返回值 (active == true?)
            .map(this::convertClaimsSet)//解析返回值中携带的信息,封装成认证对象
            .onErrorMap(e -> !(e instanceof OAuth2IntrospectionException), this::onError);
}

NimbusReactiveOpaqueTokenIntrospector 这个类里面所有的源码我都看了一边、并没有发现有什么问题。

只是对于异常处理我有点不满, 因为如果出现了异常,我作为请求资源服务的客户端看到的响应是一片空白的, 具体错误信息都放在了Response Header 里,这个我觉得不太好。到时候把他覆盖掉给他改了。

然后源码没看出什么花来,那就打断点看看,

结果在检查Http响应正确性的方法里也就是 adaptToNimbusResponse() 中发现了不对。

这是这个方法的源码

private Mono<HTTPResponse> adaptToNimbusResponse(ClientResponse responseEntity) {
 HTTPResponse response = new HTTPResponse(responseEntity.rawStatusCode());
 response.setHeader(HttpHeaders.CONTENT_TYPE, responseEntity.headers().contentType().get().toString());
 if (response.getStatusCode() != HTTPResponse.SC_OK) {
 return responseEntity.bodyToFlux(DataBuffer.class)
 .map(DataBufferUtils::release)
 .then(Mono.error(new OAuth2IntrospectionException(
 "Introspection endpoint responded with " + response.getStatusCode())));
 }
 return responseEntity.bodyToMono(String.class)
 .doOnNext(response::setContent)
 .map(body -> response);
}

在断点时,请求完成了,结果判定走进了这个 if 块。也就是请求错误。不是200响应。

所以整个流程就到了这里中断。是这个响应的 HttpStatus 是400 (Bad request) 让我有点奇怪。 为什么会是400?

因为我看到后面的处理 validate() 效验返回值逻辑,正常来说请求应该是返回200,并且带上一个 active为false 的 Response body 才对啊。

AuthorizationServer CheckToken Endpoint

于是我立马就决定去看认证服务的 check_token 端点是怎么写的。

这是 SpringSecutiryOAuth2 默认的令牌检查端点的源码,   checkToken() 方法中我打了详细的注释

/**
 * Controller which decodes access tokens for clients who are not able to do so (or where opaque token values are used).
 * 
 * @author Luke Taylor
 * @author Joel D'sa
 */
@FrameworkEndpoint
public class CheckTokenEndpoint {
 
 private ResourceServerTokenServices resourceServerTokenServices;
 
 private AccessTokenConverter accessTokenConverter = new DefaultAccessTokenConverter();
 
 protected final Log logger = LogFactory.getLog(getClass());
 
 private WebResponseExceptionTranslator<OAuth2Exception> exceptionTranslator = new DefaultWebResponseExceptionTranslator();
 
 public CheckTokenEndpoint(ResourceServerTokenServices resourceServerTokenServices) {
 this.resourceServerTokenServices = resourceServerTokenServices;
 }
 
 /**
 * @param exceptionTranslator the exception translator to set
 */
 public void setExceptionTranslator(WebResponseExceptionTranslator<OAuth2Exception> exceptionTranslator) {
 this.exceptionTranslator = exceptionTranslator;
 }
 
 /**
 * @param accessTokenConverter the accessTokenConverter to set
 */
 public void setAccessTokenConverter(AccessTokenConverter accessTokenConverter) {
 this.accessTokenConverter = accessTokenConverter;
 }
 
 @RequestMapping(value = "/oauth/check_token")
 @ResponseBody
 public Map<String, ?> checkToken(@RequestParam("token") String value) {
 
            //读取验证的 token 字符串, 封装成OAuth2AccessToken
 OAuth2AccessToken token = resourceServerTokenServices.readAccessToken(value);
 if (token == null) {
                    // 如果找不到这个 token (非法、无效) 就直接报错
 throw new InvalidTokenException("Token was not recognised");
 }
 
 if (token.isExpired()) {
                    //token 存在,但是过期了, 也直接报错
 throw new InvalidTokenException("Token has expired");
 }
 
            //解析token表示的用户信息,提取出其认证
 OAuth2Authentication authentication = resourceServerTokenServices.loadAuthentication(token.getValue());
 
            //从认证信息中提取相应字段(过期时间、用户名之类的),封装成响应
 Map<String, Object> response = (Map<String, Object>)accessTokenConverter.convertAccessToken(token, authentication);
 
            //active=true 表示这个是一个有效的 token
 // gh-1070
 response.put("active", true); // Always true if token exists and not expired
 
 return response;
 }
 
 @ExceptionHandler(InvalidTokenException.class)
 public ResponseEntity<OAuth2Exception> handleException(Exception e) throws Exception {
 logger.info("Handling error: " + e.getClass().getSimpleName() + ", " + e.getMessage());
 // This isn't an oauth resource, so we don't want to send an
 // unauthorized code here. The client has already authenticated
 // successfully with basic auth and should just
 // get back the invalid token error.
 @SuppressWarnings("serial")
 InvalidTokenException e400 = new InvalidTokenException(e.getMessage()) {
 @Override
 public int getHttpErrorCode() {
 return 400;
 }
 };
 return exceptionTranslator.translate(e400);
 }
 
}

然后看到这里我就惊了。 他这里边的逻辑显示:  token 如果发现不对,或者是 token 正确但是过期了, 就直接抛一个异常。

然后看下面的异常处理(@ExceptionHandler 注解的方法) 内部的注释,这说的是人话么

因为这不是oauth资源,因此我们不想在此处发送未经授权的代码。 ”  我懂你的意思了, 知道你不想返回403状态造成资源服务器误解,

问题是你也不能够直接怼个 400 错误请求回去啊???

看下源码修下 SpringSecurityOAuth2 的bug,解决令牌检查端点未实现 OAuth2 规范带来的坑: Resour...

先不说你返回啥400, 你光返回的不是200 就很有问题了。按照道理来说,这个接口只要进来了(即客户端身份验证已经通过了), 那么出去的响应肯定得是 200 才行

因为我看了OAuth2的文档,这是 OAuth2 令牌内省的规范。

https://www.oauth.com/oauth2-servers/token-introspection-endpoint/

里面很清楚的说到了,在下面这些情况下,都不应该返回错误响应,端点仅返回无效标志

  • 请求的令牌不存在或无效
  • 令牌已过期
  • 令牌已发出给与发出此请求的客户端不同的客户端

如果说出现了令牌过期,那么返回值应该是这样子的

HTTP/1.1 200 OK

Content-Type: application/json; charset=utf-8

{
  "active": false
}

问题解决方案

还能咋解决。 重写

这是我重写令牌检查端点后的代码:

/**
 * 覆盖掉默认的令牌检查端点 {@link CheckTokenEndpoint}
 * 提供标准的 check token response
 * https://www.oauth.com/oauth2-servers/token-introspection-endpoint/
 */
@FrameworkEndpoint
class IntrospectEndpoint {
 
    @Resource(type = DefaultTokenServices.class)
    @Lazy
    private ResourceServerTokenServices resourceServerTokenServices;
 
    private AccessTokenConverter accessTokenConverter = new DefaultAccessTokenConverter();
 
    private WebResponseExceptionTranslator<OAuth2Exception> exceptionTranslator = new RoWebResponseExceptionTranslator();
 
 
    @PostMapping("/oauth/introspect")
    @ResponseBody
    public Map<String, Object> introspect(@RequestParam("token") String value) {
 
        OAuth2AccessToken token = resourceServerTokenServices.readAccessToken(value);
 
        if (token == null) {
            return Map.of("active", false, "msg", "Token was not recognised");
        }
 
        if (token.isExpired()) {
            var builder = ImmutableMap.<String, Object>builder();
            builder.put("active", false).put("msg", "Token has expired");
 
            if (Objects.nonNull(token.getExpiration())) {
                long exp = token.getExpiration().getTime() / 1000;
                builder.put("exp", exp);
            }
 
            return builder.build();
        }
 
        OAuth2Authentication authentication = resourceServerTokenServices.loadAuthentication(token.getValue());
 
        Map<String, Object> response = (Map<String, Object>) accessTokenConverter.convertAccessToken(token, authentication);
 
        // gh-1070
        response.put("active", true);    // Always true if token exists and not expired
 
        return response;
    }
 
 
    @ExceptionHandler(OAuth2Exception.class)
    public ResponseEntity<OAuth2Exception> handleException(OAuth2Exception e) throws Exception {
        return exceptionTranslator.translate(e);
    }
}

重写令牌检查端点之后, 需要在认证服务器的 AuthorizationServerEndpointsConfigurer 配置中将端点映射路径修改, 即从原来的 /oauth/check_token 映射为自定义的端点路径。覆盖掉原先的实现。

最后的疑问

为啥你这 SpringSecurityOAuth2 WebFlux 检查令牌的流程是 按照规矩 来的  ??

为啥你这 SpringSecurityOAuth2 WebMVC 的检查令牌端点 不是按照规范实现 的??

你知道你这样搞, 资源服务和认证服务 接口对不上么??? 我佛了


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

必然

必然

凯文·凯利 (Kevin Kelly) / 周峰、董理、金阳 / 译言·东西文库/电子工业出版社 / 2016-1-1 / 58

《必然》的作者凯文·凯利,被称为“硅谷精神之父”和“世界互联网教父”。前两部《失控》和《科技想要什么》在中国出版后,引起巨大反响。书中凯文·凯利对十二种必然的科技力量加以详细的阐述,并描绘出未来三十年这些趋势如何形成合力指引我们前行的方向。 作者凯文·凯利基于过往从业经历和对未来趋势的敏锐观察对十二个关键词“形成”“知化”“流动”“屏读”“使用”“共享”“过滤”“重混”“互动”“追踪”“提问......一起来看看 《必然》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具