企业官网建设流程全解析

Spring Authorization Server 1.x 发布之后，很多团队把老项目中基于 Spring Security OAuth2 搭建的授权服务迁移了过来。迁移本身不复杂，真正卡住进度的地方，往往是标准协议覆盖不到的场景。就拿密码模式来说，Spring 官方文档里已经把它标记为 deprecated，但现实中内部管理系统、移动端 App、前后端分离的运营后台，依然大量依赖这种“拿用户名密码直接换令牌”的交互方式。更麻烦的是，标准密码模式根本没办法在认证流程里插入 MFA 二次验证、用户状态实时检查、多租户隔离这些业务逻辑。这篇文章我会从源码扩展的角度，分享一套我实际落地过的自定义密码模式方案，看完你可以直接在业务代码里扩展自己的 AuthenticationProvider，把 MFA 和复杂业务逻辑全部塞进 Spring Authorization Server 的认证链里。

1. 为什么标准OAuth2密码模式不够用

1.1 Spring Authorization Server 的默认能力边界

很多人第一次接触 Spring Authorization Server 时，会以为它和老的 Spring Security OAuth2 项目一样，通过配置就能开启所有 grant type。实际上，新框架的默认实现只内置了授权码模式、客户端凭证模式、刷新令牌模式，以及 OIDC 相关的几个扩展点。密码模式虽然在协议层面仍然可用，但在 Spring Authorization Server 中已经没有现成的实现，需要自己补全整个认证链路。

这不是框架偷懒，而是协议设计上的趋势。OAuth 2.0 安全最佳实践里，密码模式被认为是高风险模式，因为它要求客户端直接接触用户的明文密码。新框架默认不实现，就是希望开发者把精力放到授权码模式加 PKCE 的方向上。但对内部系统来说，授权码模式的跳转体验非常割裂，而且很多场景根本没有浏览器，比如服务端定时任务、内部 API 网关、以及一些老旧的嵌入式设备交互。在这些场景里，一个可控范围的自定义密码模式反而比强行套授权码更务实。

1.2 业务场景中的真实痛点

踩过坑的团队应该深有体会：标准密码模式最让人头疼的，是认证流程完全黑盒。你只能拿到用户名和密码，然后框架帮你验证一下，直接返回 token。中间想插入任何一步额外的校验都无从下手，比如：

• 用户登录时，系统需要先校验短信验证码或者 TOTP 动态口令，但密码模式的认证请求里根本没有预留这个参数，服务端也没有地方去读取和校验它。
• 企业内部有复杂的用户状态体系，用户可能被标记为“首次登录强制改密”“账号已锁定”“组织关系已调整”，这些状态都需要在发 token 之前做拦截。标准流程不提供这类钩子，你要么在认证前后硬写过滤器，要么去 hack 框架内部组件，后患无穷。
• 多租户系统里，同样一个用户名可能在不同租户下对应不同的账号和权限。标准密码模式没有租户上下文的传递和隔离机制，结果就是大家各写一套 ThreadLocal 或者参数透传，代码散落一地。

这些问题堆在一起，最终结论只有一个：不能硬套标准实现，需要基于 Spring Authorization Server 的扩展点，自己实现一个支持业务扩展的密码模式。好在这个框架本身留了足够灵活的扩展机制，只要搞懂认证链路，改造起来并不复杂。

2. 自定义密码模式的整体设计思路

2.1 认证链路的扩展原理

在动手写代码之前，先把 Spring Authorization Server 处理 token 请求的链路拆开看。所有 token 请求都会进到TokenEndpoint，框架在这里做两件事：第一，用AuthenticationConverter把HttpServletRequest里的参数转换成一个具体的Authentication对象；第二，拿着这个Authentication对象去匹配对应的AuthenticationProvider，由它来完成真正的认证。

链路中最核心的接口有三个，分别对应OAuth2AuthorizationGrantAuthenticationToken（认证参数载体）、OAuth2AuthorizationGrantAuthenticationConverter（参数解析器）、OAuth2AuthorizationGrantAuthenticationProvider（认证执行器）。默认情况下，授权码模式有一套实现，客户端凭证模式有一套实现，而我们需要的自定义密码模式，就是完全照抄这条扩展路线，写一套属于自己的实现。

这里面最容易犯的误区，是试图直接修改授权码模式的 Provider，或者在现有的过滤器链里塞逻辑。实际上最高效、最干净的做法，是新建一个自定义的 grant type，比如叫custom_password，让客户端用这个新的 grant type 发请求，框架像处理其他模式一样处理它。

2.2 方案选型：继承还是组合

具体到实现方式，有两条路可以走。第一条路是去继承现有的OAuth2ResourceOwnerPasswordAuthenticationProvider或者参考它的源码，重写内部逻辑。我当初也是这么想的，因为老项目里 Spring Security OAuth2 有一个现成的密码模式 Provider，直接抄过来改一改最快。但深入看代码后发现，Spring Authorization Server 1.x 里类的内部结构和老版本差别很大，继承之后要覆写的方法太多，而且父类内部对OAuth2AuthorizationService、OAuth2TokenGenerator的依赖都是私有字段，一旦框架升级，子类很容易被破坏。

第二条路是完全组合。自己定义一套全新的 Token 类、Converter 和 Provider，只在必要的时候调用框架暴露出来的公共服务，比如密码编码器、用户详情服务、令牌生成器。这样做虽然初期代码量多一些，但每个组件的职责单一，后续加 MFA 或者租户逻辑时，改动都被限制在自己写的类里，不会波及框架内部。

我的建议是走第二条路。如果你只想在密码模式里加一个验证码校验，用继承的方式勉强能凑合；但如果目标是“突破标准 OAuth2 限制，实现 MFA 与复杂业务集成”，那组合式扩展几乎是唯一能长期维护的选择。

2.3 自定义认证的完整流程

把整个流程画出来就清楚了：客户端请求/oauth2/token，携带grant_type=custom_password、username、password、tenant_id、mfa_code等参数。TokenEndpoint拿到请求后，依次调用已经注册的AuthenticationConverter，直到有一个 Converter 认出grant_type=custom_password并返回我们自定义的CustomPasswordAuthenticationToken。接着框架根据 Token 类型找到对应的CustomPasswordAuthenticationProvider，在 Provider 内部，先校验客户端凭证，再校验用户密码，再额外执行 MFA 校验和业务状态校验，全部通过后调用框架的OAuth2TokenGenerator生成访问令牌和刷新令牌，最终包装成OAuth2AccessTokenAuthenticationToken返回给客户端。

这条链路上，我们自己贡献的其实就是三个类，但它们恰好覆盖了从请求进入到令牌返回的所有可扩展点。理解了这层结构，后面写代码就只是照着填空。

3. 核心代码实现：从认证Token到Provider

3.1 定义自定义密码模式的认证Token

先定义认证参数的载体。这个类需要继承OAuth2AuthorizationGrantAuthenticationToken，把客户端传过来的用户名、密码、租户 ID、MFA 验证码等业务参数都封装进去。父类构造器要求传入授权范围、客户端凭证以及附加参数列表，其中附加参数会被框架记录到最终的 authorization 会话中，后面生成 ID Token 或者做审计时能用到。

public class CustomPasswordAuthenticationToken extends OAuth2AuthorizationGrantAuthenticationToken { private final String username; private final String password; private final String tenantId; private final String mfaCode; public CustomPasswordAuthenticationToken( String username, String password, String tenantId, String mfaCode, Authentication clientPrincipal, Map<String, Object> additionalParameters) { super(Collections.singletonList(new SimpleGrantedAuthority("ROLE_CUSTOM_PASSWORD")), clientPrincipal, additionalParameters); this.username = username; this.password = password; this.tenantId = tenantId; this.mfaCode = mfaCode; } public String getUsername() { return username; } public String getPassword() { return password; } public String getTenantId() { return tenantId; } public String getMfaCode() { return mfaCode; } }

这里有个细节需要注意：构造器里的additionalParameters来自框架解析请求时收集的额外参数。我在设计时没有把这些业务字段直接塞进additionalParameters去读，而是单独定义了 getter，这样 Provider 里取值时类型是安全的，也不容易因为键名拼写错误导致运行时异常。

3.2 实现认证Converter

Converter 的作用是判断当前请求是不是我们要处理的custom_password类型，并把它转换成上面定义的 Token。实现AuthenticationConverter接口，核心逻辑就集中在convert(HttpServletRequest request)方法里。需要注意的是，客户端凭证信息已经从Authorization请求头里解析出来了，通过request.getParameter("grant_type")判断类型不匹配时直接返回 null，这样框架会继续尝试下一个已注册的 Converter，不会影响其他模式。

public class CustomPasswordAuthenticationConverter implements AuthenticationConverter { @Override public Authentication convert(HttpServletRequest request) { String grantType = request.getParameter("grant_type"); if (!"custom_password".equals(grantType)) { return null; } // 解析客户端凭证 Authentication clientPrincipal = SecurityContextHolder.getContext().getAuthentication(); if (clientPrincipal == null || !(clientPrincipal instanceof OAuth2ClientAuthenticationToken)) { return null; } Map<String, Object> additionalParameters = new HashMap<>(); String username = request.getParameter("username"); String password = request.getParameter("password"); String tenantId = request.getParameter("tenant_id"); String mfaCode = request.getParameter("mfa_code"); additionalParameters.put("username", username); additionalParameters.put("tenant_id", tenantId); return new CustomPasswordAuthenticationToken( username, password, tenantId, mfaCode, clientPrincipal, additionalParameters); } }

一个小坑是客户端凭证的获取方式。TokenEndpoint在调用 Converter 之前，会把客户端身份验证结果放到SecurityContext里，所以直接用SecurityContextHolder取出OAuth2ClientAuthenticationToken是可行的。这里有极少数情况会出现取不到的问题，多半是过滤器链配置时没有把ClientAuthenticationFilter放对位置，后面排查章节会细说。

3.3 写一个可复用的AuthenticationProvider

Provider 是整个自定义模式的核心，所有认证与授权逻辑都在这里执行。实现OAuth2AuthorizationGrantAuthenticationProvider接口，核心方法是authenticate(Authentication authentication)。我按照实际业务处理顺序，把验证拆成了四步。

第一步是断言 Token 类型，如果不是CustomPasswordAuthenticationToken直接抛出异常；第二步是加载客户端详情，调用自定义的CustomClientDetailsService检查客户端是否被禁用或过期；第三步才是加载用户信息，用PasswordEncoder.matches()校验明文密码；第四步执行 MFA 和租户相关的业务校验。

public class CustomPasswordAuthenticationProvider implements OAuth2AuthorizationGrantAuthenticationProvider { private final CustomClientDetailsService clientDetailsService; private final UserDetailsService userDetailsService; private final PasswordEncoder passwordEncoder; private final MfaVerifyService mfaVerifyService; private final OAuth2AuthorizationService authorizationService; private final OAuth2TokenGenerator<?> tokenGenerator; private final OAuth2TokenCustomizer<OAuth2TokenClaimsContext> accessTokenCustomizer; // 构造器省略，使用构造器注入 @Override public Authentication authenticate(Authentication authentication) throws AuthenticationException { CustomPasswordAuthenticationToken customPasswordToken = (CustomPasswordAuthenticationToken) authentication; // 1. 校验客户端 OAuth2ClientAuthenticationToken clientPrincipal = (OAuth2ClientAuthenticationToken) customPasswordToken.getClientPrincipal(); if (!clientPrincipal.isAuthenticated()) { throw new OAuth2AuthenticationException(new OAuth2Error("invalid_client")); } // 2. 校验密码 UserDetails userDetails; try { userDetails = userDetailsService.loadUserByUsername(customPasswordToken.getUsername()); } catch (UsernameNotFoundException ex) { throw new OAuth2AuthenticationException(new OAuth2Error("invalid_grant"), ex); } if (!passwordEncoder.matches(customPasswordToken.getPassword(), userDetails.getPassword())) { throw new OAuth2AuthenticationException(new OAuth2Error("invalid_grant")); } // 3. MFA校验 boolean mfaPassed = mfaVerifyService.verify( customPasswordToken.getUsername(), customPasswordToken.getTenantId(), customPasswordToken.getMfaCode()); if (!mfaPassed) { throw new OAuth2AuthenticationException(new OAuth2Error("invalid_mfa")); } // 4. 生成令牌 OAuth2Authorization authorization = createAuthorization( customPasswordToken, userDetails, clientPrincipal); OAuth2AccessToken accessToken = authorization.getAccessToken().getToken(); Map<String, Object> tokenResponse = new HashMap<>(); tokenResponse.put(OAuth2ParameterNames.ACCESS_TOKEN, accessToken.getTokenValue()); tokenResponse.put(OAuth2ParameterNames.TOKEN_TYPE, accessToken.getTokenType().getValue()); tokenResponse.put(OAuth2ParameterNames.EXPIRES_IN, accessToken.getExpiresAt() .atOffset(ZoneOffset.UTC).toInstant().getEpochSecond() - Instant.now().getEpochSecond()); if (authorization.getRefreshToken() != null) { tokenResponse.put(OAuth2ParameterNames.REFRESH_TOKEN, authorization.getRefreshToken().getToken().getTokenValue()); } return new OAuth2AccessTokenAuthenticationToken(clientPrincipal, accessToken, authorization.getRefreshToken() == null ? null : authorization.getRefreshToken().getToken(), tokenResponse); } @Override public boolean supports(Class<?> authentication) { return CustomPasswordAuthenticationToken.class.isAssignableFrom(authentication); } }

createAuthorization这个方法要调用框架的OAuth2TokenGenerator生成访问令牌和刷新令牌，并保存到authorizationService里。这段代码相对固定，核心就两件事：构建OAuth2TokenContext，然后调用tokenGenerator.generate获取令牌对象。需要注意，如果你的TokenGenerator是DelegatingOAuth2TokenGenerator，它内部可能会有多个子生成器，比如JwtGenerator和OAuth2RefreshTokenGenerator，要保证两种 token 类型都能被覆盖，否则可能只生成 access_token 而丢了 refresh_token。

3.4 将自定义认证注册进Authorization Server

写好了上面三个类，最后一步是把它们注册到AuthorizationServerConfigurer中。这一步的代码不长，但它决定了整个链路能否跑通。在自定义的SecurityFilterChain配置里，通过 token endpoint 的扩展方法添加 Converter 和 Provider。

@Bean @Order(Ordered.HIGHEST_PRECEDENCE) public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http) throws Exception { OAuth2AuthorizationServerConfigurer authorizationServerConfigurer = new OAuth2AuthorizationServerConfigurer(); http.apply(authorizationServerConfigurer) .tokenEndpoint(tokenEndpoint -> tokenEndpoint .accessTokenRequestConverter( new CustomPasswordAuthenticationConverter()) .authenticationProvider( customPasswordAuthenticationProvider())); http.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults())); return http.build(); }

注册顺序没有严格要求，框架会按照supports()方法自动匹配。但有一点要特别注意：tokenEndpoint.accessTokenRequestConverter()方法是“追加”而不是“替换”，Spring Authorization Server 会把默认的DelegatingAuthenticationConverter和你的自定义 Converter 合到一起，也就是说授权码模式仍然在，你只是在里面多挂了一个custom_password的解析器。

注册完成后，用 curl 模拟测试一下：

curl -X POST http://localhost:8080/oauth2/token \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=custom_password" \ -d "username=admin" \ -d "password=123456" \ -d "tenant_id=tenantA" \ -d "mfa_code=123456" \ --user client-app:secret

如果返回 JSON 里包含access_token和refresh_token，说明整条链路已经通了。

4. MFA多因素认证的完整落地

4.1 MFA校验应该放在哪一步

在 Spring Authorization Server 的自定义 Provider 中，MFA 校验的插入位置非常关键。常见的错误是把它放在密码校验之前，这样攻击者可以通过枚举用户名来探测账号是否存在。正确的做法是先校验密码，再校验 MFA。密码不对，直接返回统一的invalid_grant，不要暴露“用户名存在但验证码错误”这种信息。这样从外部看，无论是用户名错误、密码错误还是 MFA 错误，报错信息都一样，能有效降低被撞库的风险。

具体到我上面的代码，MfaVerifyService.verify()方法在passwordEncoder.matches()通过之后才执行，这样的顺序还有另一个好处：即使验证码校验逻辑写得比较重，比如需要查 Redis 或调用第三方短信服务，也能避免攻击者用大量无效密码请求来打爆短信通道。

4.2 验证码存储与校验的细节

关于验证码的存储，我有几个实际踩过坑之后留下的建议。验证码不要放到数据库里，要放到 Redis 中并设置过期时间，TTL 建议控制在 5 分钟以内，具体根据业务安全策略调整。手机上收到的验证码如果 5 分钟后还能用，用户基本已经忘记这回事了，留太久不仅浪费，也增加被中间人截获的风险。

还有一个很多人容易忽略的点：验证码校验应该是“一次性”的。校验通过后立即删除，防止同一个验证码被重复使用。这个操作要放在事务边界之外，用 Redis 的del命令即可，不用引入分布式锁。如果遇到并发请求同时带着同一个验证码来登录，最好的处理方式是先get再del，并把这两个操作放进 Lua 脚本来保证原子性，或者直接使用 Redis 的getdel命令（Redis 6.2 以上支持）。

public boolean verify(String username, String tenantId, String mfaCode) { String key = "mfa:code:" + tenantId + ":" + username; String cachedCode = redisTemplate.opsForValue().get(key); if (cachedCode == null || !cachedCode.equals(mfaCode)) { return false; } redisTemplate.delete(key); return true; }

4.3 TOTP 动态口令和短信验证码怎么选

MFA 的第二步，不一定非得是“服务端下发验证码”。如果你的系统面向内部员工，我建议优先考虑 TOTP（基于时间的一次性密码）。员工在手机上安装一个标准认证器 App，首次绑定后扫码录入密钥，之后每 30 秒生成一个动态口令。这种方式的好处是没有短信通道成本，也不依赖第三方短信服务商的稳定性，离线也能用。

TOTP 实现起来也不复杂，利用java.security.MessageDigest或者成熟的库就能生成和校验。核心是利用用户绑定的密钥加上当前时间窗口计算 HMAC-SHA1，再取其中的几位数字。Spring 生态里有一个名叫otp-java的库，封装了完整的生成和校验逻辑，直接用即可。在 Provider 里接上这个服务后，mfa_code参数就代表动态口令。

如果面向 C 端用户，短信验证码更常见，但要注意防刷。同一个手机号一分钟内只能发送一次，一天内超过 5 次就要触发风控，这些策略最好放网关或者专门的验证码服务里，而不要堆在 Authorization Server 的 Provider 里，避免把认证服务写成一个什么都干的“大杂烩”。

5. 复杂业务集成的最佳实践

5.1 多租户隔离与自定义密码模式的结合

多租户场景里最难受的一点，是同一个用户名在不同租户下对应完全不同的用户记录。自定义密码模式给了一个非常好的切入点：在CustomPasswordAuthenticationToken里增加tenantId字段，loadUserByUsername时不只是根据用户名查用户，而是根据tenantId + username联合查询。

这里有一个细节：框架默认的UserDetailsService接口只有loadUserByUsername(String username)一个方法，没有地方传租户 ID。我的做法是自定义一个TenantAwareUserDetailsService接口，核心方法改成loadUserByUsername(String username, String tenantId)。这个接口不依赖框架，完全是我自己定义的，Provider 里直接调用它，不去调用框架默认的UserDetailsService。这样就能绕开标准接口的参数限制。

租户 ID 的传递不仅发生在认证阶段。登录成功后，用户名和租户 ID 会作为additionalParameters保存在OAuth2Authorization里。后续业务系统拿到 access_token 后，如果想要获取用户的租户上下文，可以在网关或业务系统中解析 token，把租户 ID 放到请求头里传递。如果你用的是 JWT 格式的 token，可以在生成 token 时把tenantId放到 JWT 的 claims 里，这样业务系统解析 token 就能直接拿到租户信息，不用再查库。做法是配置一个OAuth2TokenCustomizer：

@Bean public OAuth2TokenCustomizer<OAuth2TokenClaimsContext> accessTokenCustomizer() { return context -> { OAuth2Authorization authorization = (OAuth2Authorization) ((OAuth2TokenClaimsContext) context).getPrincipal(); Map<String, Object> additionalParams = authorization.getAttributes(); context.getClaims().claim("tenant_id", additionalParams.getOrDefault("tenant_id", "default")); }; }

5.2 用户状态实时检查与登录审计

很多团队把用户状态检查放到授权服务器之外，比如在业务系统里拦截请求时判断用户是否有权限。但这样有一个问题：用户已经被禁用、离职或者组织关系发生变化后，他手里已经拿到的 token 仍然能访问系统，直到 token 过期。对内部系统来说，token 有效期通常设置得比较长（比如 8 小时甚至一天），这期间安全漏洞实在太大。

所以在自定义密码模式的 Provider 里，我加入了用户状态检查。具体来说，在密码校验通过之后、MFA 校验之前，调用一次TenantAwareUserDetailsService返回的 UserDetails，检查它是否实现了自定义的UserStatusAware接口。如果用户被标记为锁定、禁用或首次登录，则抛出对应的OAuth2AuthenticationException，错误码可以设置成account_locked、user_disabled、password_expired。这样客户端能拿到更明确的错误原因，用户侧也可以据此给出更友好的提示文案。

if (userDetails instanceof UserStatusAware statusAware) { if (statusAware.isLocked()) { throw new OAuth2AuthenticationException(new OAuth2Error("account_locked")); } if (!statusAware.isEnabled()) { throw new OAuth2AuthenticationException(new OAuth2Error("user_disabled")); } }

除了状态检查，登录审计也值得在这一层做。每次成功的密码认证都记录一条审计日志，包含用户名、租户 ID、客户端 ID、来源 IP、登录时间。这个日志对于后续排查安全问题和追溯操作人非常有帮助。做法可以是在 Provider 里注入一个LoginAuditService，认证成功后异步记录日志，注意不要影响主流程的响应速度。

5.3 与Spring Security其他扩展点联动

Spring Authorization Server 毕竟还是基于 Spring Security 的，所以很多 Spring Security 的扩展点都可以无缝复用。比如在 Provider 里注入AuthenticationEventPublisher，通过它发布认证成功或失败的事件，事件监听器可以做风控告警、用户行为分析等后续处理。这样一来，自定义密码模式就不仅仅是一个登录入口，而是一个可以承接各种业务规则的事件源。

还有一个很实用的联动场景是验证码发送。很多系统要求“用户输入密码和验证码后，先校验验证码，再发短信”或者“密码错误次数过多时，要求输入验证码”。这个逻辑在 Provider 里做起来非常顺畅：加载用户后，先判断用户最近的失败次数，如果超过阈值，就强制要求请求里携带mfa_code，如果没有或者校验失败，就拒绝访问。这样就把验证码从“可选”变成了“条件必选”，安全性大大提高。

6. 常见问题与排查技巧实录

6.1 典型报错与解决方案汇总

在开发过程中，我整理了一份高频问题清单，如果你在落地自定义密码模式时遇到了类似报错，可以直接对照排查。

6.2 调试技巧与日志分析思路

调试 Spring Authorization Server 时，最怕的就是“黑盒”看不到内部流程。建议在本地开发环境把日志级别调到 DEBUG，重点观察TokenEndpoint、OAuth2AuthorizationGrantAuthenticationConverter和自定义 Provider 的调用日志。这样能清晰地看到请求走到了哪一步、被哪个类拦截、在哪里抛出的异常。

logging.level.org.springframework.security=DEBUG logging.level.org.springframework.security.oauth2.server=DEBUG logging.level.com.example.authserver=DEBUG

如果 DEBUG 日志太多看不清楚，直接在你的 Converter 和 Provider 里打业务日志，打印每个参数的解析结果和每条校验规则的执行结果。要知道，invalid_grant这个错误码是高度抽象的，它可能由七八种原因触发。没有日志，排查起来全靠猜。

我还有一个非常推荐的排查手段：用 Postman 或者 IDEA 的 HTTP Client，手动组装完整的 token 请求，去掉所有无关参数，逐个字段验证。先用grant_type=client_credentials跑通客户端凭证模式，确认 TokenEndpoint 本身没问题；再用grant_type=custom_password请求，把异常信息逐步收窄到自定义代码上。

6.3 上线前检查清单

项目上线前，除了功能要跑通，还有一些容易被忽略的坑。第一，access_token的有效期和refresh_token的有效期要分别设置合理值。内部系统建议 access token 设置 2 小时，refresh token 设置 12 小时或 24 小时，不要图省事直接配到 7 天。第二，配置好的 Token 端点是否做了 TLS 加密，所有 token 请求都必须在 HTTPS 下传输，否则明文密码和令牌在网络上裸奔，自定义模式本身的安全优势就荡然无存。第三，登录失败的错误信息需要统一格式化，不能把底层异常信息直接抛给前端。

有一个我在生产环境踩过的坑是：使用 Redis 存储OAuth2Authorization时，如果同一个客户端实例的 ID 发生了重复，会导致 token 被意外覆盖。这个问题的本质和自定义密码模式无关，属于OAuth2AuthorizationService的键设计问题，但遇到时非常隐蔽。最后解决方案是统一给授权记录增加一个唯一 ID，避免和 client 的主键冲突。所以我在这里强烈建议，如果业务量不大，优先使用自带的JdbcOAuth2AuthorizationService，它的建表语句和索引都是官方验证过的，稳定性更高。

收尾：一点项目落地后的体会

前前后后这套自定义密码模式的改造，我在生产环境维护了近一年。最初只想解决一个“登录时多校验一步验证码”的小需求，结果发现一旦抓住了 Spring Authorization Server 的扩展思路，后面加租户隔离、加登录审计、加条件性 MFA 都不是什么大工程了。整个过程最大的成本不在写代码，而在理解框架约定：谁负责解析参数、谁负责校验身份、谁负责生成令牌，这些边界理清了，自定义模式只是又一个 grant type 而已。

最后分享一个建议给准备动手的团队：不要一上来就追求完整的企业级方案。先用最简化的三步——自定义 Token、Converter、Provider——把自定义密码模式跑通，让前端可以用grant_type=custom_password换到 token。这个过程中不要混入任何附加业务。等链路稳定之后，再逐步把 MFA、租户隔离、审计日志这些能力往 Provider 里加。每个阶段都保持可回滚的状态。毕竟，认证授权是系统的第一道门，门如果打不开或者关不严，业务再花哨也白搭。