在无服务器环境（AWS Lambda）中高效存储与刷新Bearer令牌

在无服务器环境下处理这种限时OAuth令牌，我常用这几个方案，你可以根据自己的业务场景和复杂度需求来选：

1. Lambda执行环境全局变量缓存（最简单低成本） #

Lambda的执行环境会被复用（也就是所谓的"warm start"），我们可以利用这个特性在handler函数外部定义全局变量来缓存令牌和过期时间，每次调用时先检查令牌是否有效：

import requests
import time

# 全局变量，缓存令牌和过期时间
cached_token = None
token_expiry = 0

def lambda_handler(event, context):
    global cached_token, token_expiry
    current_time = time.time()
    
    # 检查令牌是否过期或未初始化
    if cached_token is None or current_time >= token_expiry:
        # 调用OAuth端点获取新令牌
        auth_response = requests.post("https://your-oauth-endpoint/token", data={
            "grant_type": "client_credentials",
            "client_id": "your-id",
            "client_secret": "your-secret"
        })
        auth_data = auth_response.json()
        cached_token = auth_data["access_token"]
        # 设置过期时间，留10分钟缓冲避免网络延迟导致过期
        token_expiry = current_time + auth_data["expires_in"] - 600
    
    # 使用缓存的令牌调用外部API
    api_response = requests.get("https://external-api/resource", headers={
        "Authorization": f"Bearer {cached_token}"
    })
    return api_response.json()

优点：零额外成本，实现简单，大部分warm start场景下能避免重复请求令牌。
缺点：冷启动（第一次调用或环境被销毁后）还是要请求新令牌；令牌只在单个执行环境内有效，多个并发执行的环境可能会重复请求。

2. AWS Secrets Manager + 自动令牌轮换（生产环境首选） #

如果需要更可靠的缓存、跨Lambda共享令牌，或者要符合安全合规要求，用Secrets Manager是最佳选择：

1. 在Secrets Manager中创建一个存储令牌的秘密，初始值可以先手动获取一个令牌。
2. 编写一个轮换Lambda函数，这个函数会定期调用OAuth端点获取新令牌，然后更新Secrets Manager中的秘密值。你可以在Secrets Manager里配置自动轮换的频率（比如23小时，比令牌有效期少1小时，留缓冲）。
3. 你的业务Lambda函数每次调用时，直接从Secrets Manager获取最新的令牌即可。

优点：令牌集中存储且加密，自动轮换无需业务代码关心过期；跨所有Lambda执行环境共享，不会重复请求；自带审计日志，符合安全要求。
缺点：Secrets Manager有少量成本（按请求次数和存储量计费）；每次获取令牌会有轻微的网络延迟，但可以接受。

3. ElastiCache（Redis/Memcached）（多函数共享或高并发场景） #

如果你的系统有多个Lambda函数需要使用同一个令牌，或者并发量极高，ElastiCache是合适的选择：

1. 创建一个ElastiCache集群（推荐Redis，支持过期时间）。
2. 业务Lambda函数每次调用时，先从Redis中获取令牌：
   • 如果令牌存在且未过期，直接使用；
   • 如果令牌不存在或已过期，调用OAuth端点获取新令牌，并存入Redis，同时设置和令牌有效期一致的过期时间（同样留缓冲）。

优点：跨所有Lambda执行环境甚至其他服务共享令牌；Redis的过期机制自动处理令牌失效，无需手动跟踪；高并发下能有效减少OAuth端点的请求量。
缺点：需要维护ElastiCache集群，成本更高；Lambda需要配置VPC访问权限，增加了一点复杂度。

额外最佳实践 #

• 重试机制：调用OAuth端点获取令牌时，要实现指数退避重试逻辑，避免临时网络故障导致失败。
• 令牌加密：不管用哪种方案，令牌都要加密存储（Secrets Manager自动加密，Redis可以开启传输加密），不要明文写在代码里。
• 日志监控：记录令牌获取的成功/失败日志，以及令牌的使用情况，方便排查问题。

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