devbox
笔触狂放9
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Spring Security Oauth2认证源码解析_spring security oauth2源码解析

作者：笔触狂放9 | 2024-02-15 11:10:05

赞

踩

spring security oauth2源码解析

        本文开始从源码的层面，讲解一些Spring Security Oauth2的认证流程。本文较长，适合在空余时间段观看。且涉及了较多的源码，非关键性代码以…代替。

准备工作

        首先开启debug信息：

  1. logging:
  2.   level:
  3.     org.springframework: DEBUG

        可以完整的看到内部的运转流程。

        client模式稍微简单一些，使用client模式获取token 
http://localhost:8080/oauth/token?client_id=client_1&client_secret=123456&scope=select&grant_type=client_credentials

        由于debug信息太多了，我简单按照顺序列了一下关键的几个类：

  1. ClientCredentialsTokenEndpointFilter
  2. DaoAuthenticationProvider
  3. TokenEndpoint
  4. TokenGranter


@EnableAuthorizationServer

        上一篇博客中我们尝试使用了password模式和client模式，有一个比较关键的endpoint：/oauth/token。从这个入口开始分析，spring security oauth2内部是如何生成token的。获取token，与第一篇文章中的两个重要概念之一有关，也就是AuthorizationServer与ResourceServer中的AuthorizationServer。

        在之前的配置中

  1. @Configuration
  2. @EnableAuthorizationServer
  3. protected static class AuthorizationServerConfiguration extends AuthorizationServerConfigurerAdapter {}


        出现了AuthorizationServerConfigurerAdapter 关键类，他关联了三个重要的配置类，分别是

  1. public class AuthorizationServerConfigurerAdapter implements AuthorizationServerConfigurer {
  2.  
  3.     @Override
  4.     public void configure(AuthorizationServerSecurityConfigurer security <1>) throws Exception {
  5.     }
  6.  
  7.     @Override
  8.     public void configure(ClientDetailsServiceConfigurer clients <2>) throws Exception {
  9.     }
  10.  
  11.     @Override
  12.     public void configure(AuthorizationServerEndpointsConfigurer endpoints <3>) throws Exception {
  13.     }
  14.  
  15. }

  1. 配置AuthorizationServer安全认证的相关信息，创建ClientCredentialsTokenEndpointFilter核心过滤器
  2. 配置OAuth2的客户端相关信息
  3.  配置AuthorizationServerEndpointsConfigurer众多相关类，包括配置身份认证器，配置认证方式，TokenStore，TokenGranter，OAuth2RequestFactory

        我们逐步分析其中关键的类

客户端身份认证核心过滤器ClientCredentialsTokenEndpointFilter（掌握）

        截取关键的代码，可以分析出大概的流程 
在请求到达 /oauth/token 之前经过了 ClientCredentialsTokenEndpointFilter 这个过滤器，关键方法如下

  1. public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response)
  2.         throws AuthenticationException, IOException, ServletException {
  3.     ...
  4.     String clientId = request.getParameter("client_id");
  5.     String clientSecret = request.getParameter("client_secret");
  6.  
  7.     ...
  8.     clientId = clientId.trim();
  9.     UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken(clientId,
  10.             clientSecret);
  11.  
  12.     return this.getAuthenticationManager().authenticate(authRequest);
  13.  
  14. }


顶级身份管理者AuthenticationManager（掌握）


        用来从请求中获取client_id,client_secret，组装成一个UsernamePasswordAuthenticationToken作为身份标识，使用容器中的顶级身份管理器AuthenticationManager去进行身份认证（AuthenticationManager的实现类一般是ProviderManager。而ProviderManager内部维护了一个List,真正的身份认证是由一系列AuthenticationProvider去完成。而AuthenticationProvider的常用实现类则是DaoAuthenticationProvider，DaoAuthenticationProvider内部又聚合了一个UserDetailsService接口，UserDetailsService才是获取用户详细信息的最终接口，而我们上一篇文章中在内存中配置用户，就是使用了UserDetailsService的一个实现类InMemoryUserDetailsManager）。UML类图可以大概理解下这些类的关系，省略了授权部分。

  图1 认证相关UML类图

        可能机智的读者会发现一个问题，我前面一篇文章已经提到了client模式是不存在“用户”的概念的，那么这里的身份认证是在认证什么呢？debug可以发现UserDetailsService的实现被适配成了ClientDetailsUserDetailsService，这个设计是将client客户端的信息（client_id,client_secret）适配成用户的信息(username,password)，这样我们的认证流程就不需要修改了。
        经过ClientCredentialsTokenEndpointFilter之后，身份信息已经得到了AuthenticationManager的验证。接着便到达了：TokenEndpoint。

Token处理端点TokenEndpoint（掌握）


        前面的两个 ClientCredentialsTokenEndpointFilter 和 AuthenticationManager 可以理解为一些前置校验，和身份封装，而这个类一看名字就知道和我们的token是密切相关的。

  1. @FrameworkEndpoint
  2. public class TokenEndpoint extends AbstractEndpoint {
  3.  
  4.     @RequestMapping(value = "/oauth/token", method=RequestMethod.POST)
  5.     public ResponseEntity<OAuth2AccessToken> postAccessToken(Principal principal, @RequestParam
  6.     Map<String, String> parameters) throws HttpRequestMethodNotSupportedException {
  7.          ...
  8.         String clientId = getClientId(principal);
  9.         ClientDetails authenticatedClient = getClientDetailsService().loadClientByClientId(clientId);//<1>
  10.         ...
  11.         TokenRequest tokenRequest = getOAuth2RequestFactory().createTokenRequest(parameters, authenticatedClient);//<2>
  12.         ...
  13.         OAuth2AccessToken token = getTokenGranter().grant(tokenRequest.getGrantType(), tokenRequest);//<3>
  14.         ...
  15.         return getResponse(token);
  16.  
  17.     }
  18.  
  19.     private TokenGranter tokenGranter;
  20. }

  1. 加载客户端信息
  2.  结合请求信息，创建TokenRequest
  3. 将TokenRequest传递给TokenGranter颁发token

        省略了一些校验代码之后，真正的 /oauth/token 端点暴露在了我们眼前，其中方法参数中的Principal经过之前的过滤器，已经被填充了相关的信息，而方法的内部则是依赖了一个TokenGranter 来颁发token。其中 OAuth2AccessToken 的实现类 DefaultOAuth2AccessToken 就是最终在控制台得到的token序列化之前的原始类:

  1. public class DefaultOAuth2AccessToken implements Serializable, OAuth2AccessToken {
  2.  
  3.     private static final long serialVersionUID = 914967629530462926L;
  4.  
  5.     private String value;
  6.  
  7.     private Date expiration;
  8.  
  9.     private String tokenType = BEARER_TYPE.toLowerCase();
  10.  
  11.     private OAuth2RefreshToken refreshToken;
  12.  
  13.     private Set<String> scope;
  14.  
  15.     private Map<String, Object> additionalInformation = Collections.emptyMap();
  16.  
  17.     //getter,setter
  18. }
  19.  
  20.  
  21. @org.codehaus.jackson.map.annotate.JsonSerialize(using = OAuth2AccessTokenJackson1Serializer.class)
  22. @org.codehaus.jackson.map.annotate.JsonDeserialize(using = OAuth2AccessTokenJackson1Deserializer.class)
  23. @com.fasterxml.jackson.databind.annotation.JsonSerialize(using = OAuth2AccessTokenJackson2Serializer.class)
  24. @com.fasterxml.jackson.databind.annotation.JsonDeserialize(using = OAuth2AccessTokenJackson2Deserializer.class)
  25.  
  26. public interface OAuth2AccessToken {
  27.  
  28.     public static String BEARER_TYPE = "Bearer";
  29.  
  30.     public static String OAUTH2_TYPE = "OAuth2";
  31.  
  32.     /**
  33.      * The access token issued by the authorization server. This value is REQUIRED.
  34.      */
  35.     public static String ACCESS_TOKEN = "access_token";
  36.  
  37.     /**
  38.      * The type of the token issued as described in <a
  39.      * href="http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-7.1">Section 7.1</a>. Value is case insensitive.
  40.      * This value is REQUIRED.
  41.      */
  42.     public static String TOKEN_TYPE = "token_type";
  43.  
  44.     /**
  45.      * The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will
  46.      * expire in one hour from the time the response was generated. This value is OPTIONAL.
  47.      */
  48.     public static String EXPIRES_IN = "expires_in";
  49.  
  50.     /**
  51.      * The refresh token which can be used to obtain new access tokens using the same authorization grant as described
  52.      * in <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-6">Section 6</a>. This value is OPTIONAL.
  53.      */
  54.     public static String REFRESH_TOKEN = "refresh_token";
  55.  
  56.     /**
  57.      * The scope of the access token as described by <a
  58.      * href="http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3">Section 3.3</a>
  59.      */
  60.     public static String SCOPE = "scope";
  61.  
  62.     ...
  63. }


        一个典型的样例token响应,如下所示，就是上述类序列化后的结果：

  1. { 
  2.     "access_token":"950a7cc9-5a8a-42c9-a693-40e817b1a4b0", 
  3.     "token_type":"bearer", 
  4.     "refresh_token":"773a0fcd-6023-45f8-8848-e141296cb3cb", 
  5.     "expires_in":27036, 
  6.     "scope":"select" 
  7. }


TokenGranter（掌握）


        先从UML类图对TokenGranter接口的设计有一个宏观的认识


图2 TokenGranter相关UML类图

        TokenGranter的设计思路是使用CompositeTokenGranter管理一个List列表，每一种grantType对应一个具体的真正授权者，在debug过程中可以发现 CompositeTokenGranter 内部就是在循环调用五种 TokenGranter 实现类的grant方法，而granter内部则是通过grantType来区分是否是各自的授权类型。

  1. public class CompositeTokenGranter implements TokenGranter {
  2.  
  3.     private final List<TokenGranter> tokenGranters;
  4.  
  5.     public CompositeTokenGranter(List<TokenGranter> tokenGranters) {
  6.         this.tokenGranters = new ArrayList<TokenGranter>(tokenGranters);
  7.     }
  8.  
  9.     public OAuth2AccessToken grant(String grantType, TokenRequest tokenRequest) {
  10.         for (TokenGranter granter : tokenGranters) {
  11.             OAuth2AccessToken grant = granter.grant(grantType, tokenRequest);
  12.             if (grant!=null) {
  13.                 return grant;
  14.             }
  15.         }
  16.         return null;
  17.     }
  18. }


        五种类型分别是：

ResourceOwnerPasswordTokenGranter ==> password密码模式
AuthorizationCodeTokenGranter ==> authorization_code授权码模式
ClientCredentialsTokenGranter ==> client_credentials客户端模式
ImplicitTokenGranter ==> implicit简化模式
RefreshTokenGranter ==>refresh_token 刷新token专用
以客户端模式为例，思考如何产生token的，则需要继续研究5种授权者的抽象类：AbstractTokenGranter

  1. public abstract class AbstractTokenGranter implements TokenGranter {
  2.  
  3.     protected final Log logger = LogFactory.getLog(getClass());
  4.  
  5.     //与token相关的service，重点
  6.     private final AuthorizationServerTokenServices tokenServices;
  7.     //与clientDetails相关的service，重点
  8.     private final ClientDetailsService clientDetailsService;
  9.     //创建oauth2Request的工厂，重点
  10.     private final OAuth2RequestFactory requestFactory;
  11.  
  12.     private final String grantType;
  13.     ...
  14.  
  15.     public OAuth2AccessToken grant(String grantType, TokenRequest tokenRequest) {
  16.  
  17.         ...
  18.         String clientId = tokenRequest.getClientId();
  19.         ClientDetails client = clientDetailsService.loadClientByClientId(clientId);
  20.         validateGrantType(grantType, client);
  21.  
  22.         logger.debug("Getting access token for: " + clientId);
  23.  
  24.         return getAccessToken(client, tokenRequest);
  25.  
  26.     }
  27.  
  28.     protected OAuth2AccessToken getAccessToken(ClientDetails client, TokenRequest tokenRequest) {
  29.         return tokenServices.createAccessToken(getOAuth2Authentication(client, tokenRequest));
  30.     }
  31.  
  32.     protected OAuth2Authentication getOAuth2Authentication(ClientDetails client, TokenRequest tokenRequest) {
  33.         OAuth2Request storedOAuth2Request = requestFactory.createOAuth2Request(client, tokenRequest);
  34.         return new OAuth2Authentication(storedOAuth2Request, null);
  35.     }
  36.  
  37.     ...
  38. }

        回过头去看TokenEndpoint中，正是调用了这里的三个重要的类变量的相关方法。由于篇幅限制，不能延展太多，不然没完没了，所以重点分析下 AuthorizationServerTokenServices 是何方神圣。

  1. AuthorizationServerTokenServices（了解）
  2. AuthorizationServer端的token操作service，接口设计如下：
  3.  
  4. public interface AuthorizationServerTokenServices {
  5.     //创建token
  6.     OAuth2AccessToken createAccessToken(OAuth2Authentication authentication) throws AuthenticationException;
  7.     //刷新token
  8.     OAuth2AccessToken refreshAccessToken(String refreshToken, TokenRequest tokenRequest)
  9.             throws AuthenticationException;
  10.     //获取token
  11.     OAuth2AccessToken getAccessToken(OAuth2Authentication authentication);
  12.  
  13. }


        在默认的实现类DefaultTokenServices中，可以看到token是如何产生的，并且了解了框架对token进行哪些信息的关联。

  1. @Transactional
  2. public OAuth2AccessToken createAccessToken(OAuth2Authentication authentication) throws AuthenticationException {
  3.  
  4.     OAuth2AccessToken existingAccessToken = tokenStore.getAccessToken(authentication);
  5.     OAuth2RefreshToken refreshToken = null;
  6.     if (existingAccessToken != null) {
  7.         if (existingAccessToken.isExpired()) {
  8.             if (existingAccessToken.getRefreshToken() != null) {
  9.                 refreshToken = existingAccessToken.getRefreshToken();
  10.                 // The token store could remove the refresh token when the
  11.                 // access token is removed, but we want to
  12.                 // be sure...
  13.                 tokenStore.removeRefreshToken(refreshToken);
  14.             }
  15.             tokenStore.removeAccessToken(existingAccessToken);
  16.         }
  17.         else {
  18.             // Re-store the access token in case the authentication has changed
  19.             tokenStore.storeAccessToken(existingAccessToken, authentication);
  20.             return existingAccessToken;
  21.         }
  22.     }
  23.  
  24.     // Only create a new refresh token if there wasn't an existing one
  25.     // associated with an expired access token.
  26.     // Clients might be holding existing refresh tokens, so we re-use it in
  27.     // the case that the old access token
  28.     // expired.
  29.     if (refreshToken == null) {
  30.         refreshToken = createRefreshToken(authentication);
  31.     }
  32.     // But the refresh token itself might need to be re-issued if it has
  33.     // expired.
  34.     else if (refreshToken instanceof ExpiringOAuth2RefreshToken) {
  35.         ExpiringOAuth2RefreshToken expiring = (ExpiringOAuth2RefreshToken) refreshToken;
  36.         if (System.currentTimeMillis() > expiring.getExpiration().getTime()) {
  37.             refreshToken = createRefreshToken(authentication);
  38.         }
  39.     }
  40.  
  41.     OAuth2AccessToken accessToken = createAccessToken(authentication, refreshToken);
  42.     tokenStore.storeAccessToken(accessToken, authentication);
  43.     // In case it was modified
  44.     refreshToken = accessToken.getRefreshToken();
  45.     if (refreshToken != null) {
  46.         tokenStore.storeRefreshToken(refreshToken, authentication);
  47.     }
  48.     return accessToken;
  49.  
  50. }


        简单总结一下 AuthorizationServerTokenServices 的作用，他提供了创建token，刷新token，获取token的实现。在创建token时，他会调用tokenStore对产生的token和相关信息存储到对应的实现类中，可以是redis，数据库，内存，jwt。

总结


        本篇总结了使用客户端模式获取Token时，spring security oauth2内部的运作流程，重点是在分析 AuthenticationServer 相关的类。其他模式有一定的不同，但抽象功能是固定的，只是具体的实现类会被相应地替换。

        阅读spring的源码，会发现它的设计中出现了非常多的抽象接口，这对我们理清楚内部工作流程产生了不小的困扰，我的方式是可以借助UML类图，先从宏观理清楚作者的设计思路，这会让我们的分析事半功倍。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/笔触狂放9/article/detail/83994
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号