三个请求同时撞上令牌过期，登录为什么会变成一场竞速？

三个请求同时发出，恰好赶上访问令牌过期。如果每个请求各自去刷新，第一次交换就可能让另外两个正要使用的刷新令牌失效。一个登录功能，就这样变成了请求之间的竞速。

Codename One 是一个开源框架，用同一套 Java 或 Kotlin 代码库构建原生 iOS、Android、桌面和 Web 应用。本周的安全工作，把客户端和后端围绕这些令牌转换衔接了起来：客户端可以协调续期，服务端可以轮换令牌，测试则能验证真实请求被拒之后会发生什么。

把访问规则放在路由旁边

后端在 com.codename1.backend.security 下提供了 Spring 风格的安全链。一条链先选择它处理哪些请求，再对它们做认证和授权。安全指南示例中的这段代码，用 JWT 作用域保护了一个 API：

@Bean
@Order(1)
SecurityFilterChain api(HttpSecurity http) {
http.securityMatcher("/api/**")
.authorizeHttpRequests(auth -> auth
.requestMatchers("/api/orders/**").hasAuthority("SCOPE_orders:read")
.anyRequest().authenticated())
.sessionManagement(session ->
session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
return http.build();
}

配置可信的签发方和 API 期望的受众。指南中的配置键包括 cn1.security.oauth2.resourceserver.jwt.issuer-uri 和 cn1.security.oauth2.resourceserver.jwt.audiences。受众检查在未配置时是可选的，所以当多个服务共享同一个签发方时，要有意识地设置它。

没有 SecurityFilterChain bean 的后端就没有安全层。添加依赖并不会让路由变安全。无状态链也不会自带 CSRF 过滤器，除非你主动要求。基于会话的浏览器应用威胁模型不同，需要相应的会话与 CSRF 配置。

@PreAuthorize 这类方法规则会被编译成检查。它们可以作用于自调用和私有方法，因为构建过程把它们织入方法本身，而不是依赖调用经过运行时代理。表达式语言是一个受支持的子集；ACL、@PostAuthorize 和任意表达式求值不在其中。

给客户端指定唯一的续期负责人

把已安装的应用注册为公共 OAuth 客户端，使用精确的重定向 URI 和 PKCE。嵌在应用里的客户端密钥不可能保持机密。配置好 OidcClient 之后，为 API 基础 URL 安装一个授权器：

OidcRequestAuthorizer authorizer =
new OidcRequestAuthorizer(client).install("https://api.example.com/v1");
authorizer.addSignInRequiredListener((source, reason) -> showSignIn());
authorizer.load().ready(saved -> {
if (saved == null) {
showSignIn();
} else {
showNotes();
}
});

这是一段应用示例：client 已用你的提供方和令牌存储配置好；showSignIn() 和 showNotes() 是你的 UI 方法。用 SecureStorageTokenStore 做平台保护的持久化。明文存储回退是一个显式选项，不该被应用悄悄启用来让错误消失。

授权器先匹配协议、主机和端口，再匹配完整的路径段。/v1 包含 /v1/notes，但不包含 /v10。它覆盖普通的 ConnectionRequest 调用、REST 构建器以及通过网络层接入的生成客户端。

续期默认在过期前启动。交换期间排队的请求会等待它的结果。如果带令牌的请求收到 401，授权器可以刷新并重试一次，调用方拿到最终响应。刷新被拒会结束会话、清除已存令牌并调用登录监听器。如果你的请求从流中写入请求体，在依赖重试之前，先确认你的实现能再次提供它。

对于 Codename One 跟随的重定向，令牌会在注册来源或路径之外被移除。当前的 iOS 移植版让系统在应用代码看到之前就跟随重定向。把受保护的 API 重定向限制在你控制的主机内；不要推断所有传输层都有相同的重定向拦截点。

选择你的部署能共享的状态

后端包含表单登录、HTTP Basic、API 密钥、JWT 资源服务器、OAuth 登录和授权服务器支持。MFA 包含 TOTP 和恢复码；passkey 端点使用 WebAuthn。这些是各自独立配置的机制，不是一个能让所有部署都变安全的开关。

多个实例无法共享内存中的令牌仓库或限流器。当你的部署形态如此时，要声明数据库支持的存储。cn1.security.schema.enabled=true 应放在模块构建时的 application.properties 里，它会注册安全迁移。它创建表，但不会替你选择 JDBC 存储。

刷新令牌和一次性代码必须原子消费。否则两个实例可能同时接受同一个密钥。JDBC 实现用条件数据库操作及其影响行数来做这些判断。TOTP 密钥在配置的加密密钥下密封；密码哈希和一次性恢复码有各自的存储规则。

打包后的服务器只链接其安全链触及的机制。一个验证令牌的 API 不必携带登录页面和密码存储。这是显式配置与死代码消除带来的结果，但它并不减少审查已启用规则的必要性。

测试登录成功之后的失败

端到端客户端测试连接 HelloCodenameOne 后端。BackendTokenRefreshTest 故意用一个服务器未签名的访问令牌替换原令牌。它检查生成客户端在续期后收到一次成功响应、刷新令牌发生轮换，以及重用已花费的刷新令牌会结束会话。

这比一个总是返回已认证用户的 mock 证明了更多东西。它把客户端的网络与令牌状态，同服务器的令牌端点和受保护路由放在一起检验。

凭据与重定向测试会明确报告浏览器跳过，因为浏览器拥有那些 cookie 和重定向。一套全绿的端口测试要结合这些跳过项来读。WebAuthn PRF 桥接覆盖使用 Chromium 的虚拟认证器；这并不代表每个硬件认证器都支持该扩展。

SAML、LDAP、不透明令牌内省以及若干授权服务器扩展不在本版本范围内。后端安全指南和客户端身份指南规定了受支持的表面。PR #5961 把这些部分连接起来。