AWS Cognito 如何通过refreshToken等方式实现idToken永久有效？

核心实现逻辑 #

AWS Cognito原生支持通过refreshToken无感刷新idToken，无需用户重复登录，核心前提如下：

1. 先调整Cognito用户池的refreshToken有效期配置：在用户池侧边栏选择「应用程序集成」-「应用程序客户端列表」，点击对应应用客户端的「编辑」按钮，可将refreshToken有效期最高设置为10年，远长于idToken最多24小时的有效期限制。
2. 触发刷新的时机：你可以选择在idToken过期前5-10分钟主动触发刷新，或是在接口返回idToken无效的错误时被动触发刷新。刷新时调用Cognito的InitiateAuth接口，选择REFRESH_TOKEN_AUTH/REFRESH_TOKEN认证流，传入当前有效的refreshToken，即可直接获取新的idToken和accessToken，全程不需要用户参与交互。

如果使用AWS官方SDK（如aws-amplify、iOS/Android官方Cognito SDK），调用Auth.currentSession()这类封装好的方法时，SDK会自动判断token有效性，内部完成刷新逻辑，不需要手动编写刷新代码。

服务端实现最佳实践 #

• 禁止在服务端存储refreshToken：refreshToken是长期有效敏感凭证，必须存储在客户端侧，Web端推荐使用带HttpOnly、Secure、SameSite属性的Cookie存储，移动端推荐使用系统提供的安全存储能力（如iOS的Keychain、Android的Keystore），避免凭证泄露风险。
• 网关层统一做token校验：可在API网关层统一解析校验idToken的exp（过期时间戳）字段，当检测到idToken已过期时，返回约定的专属错误码（如498 Token Expired），客户端收到该错误码后自动触发刷新流程，刷新完成后自动重试原请求，用户完全无感知。
• 补充refreshToken吊销校验：遇到用户主动登出、修改密码、账号被封禁等场景时，必须主动调用Cognito的AdminRevokeAuthSession接口吊销对应用户的refreshToken，每次刷新请求到来时先校验refreshToken是否已被吊销，避免失效凭证被滥用。
• 避免并发刷新冲突：客户端侧的刷新逻辑需要加全局锁，同一个refreshToken同一时间只能发起一次刷新请求，避免多并发请求同时刷新导致Cognito返回报错，打断正常业务流程。
• 不要依赖本地时间做过期判断：所有idToken有效期校验都基于JWT内置的exp字段和服务端/UTC标准时间对比，避免客户端本地时间不准导致刷新逻辑异常。

当refreshToken本身到期时，才需要引导用户重新登录，只要将refreshToken的有效期设置为符合业务预期的时长（如1年），即可实现和主流互联网产品一致的长期登录体验。

内容的提问来源于stack exchange，提问作者Test