Apple 登录后端：验证、映射与业务会话
identityToken 是 Apple 签发的身份声明；你自己的 API 通常需要自己签发和管理的会话。
用你的前端经验理解
你可以用 Node/Hono 或 NestJS 接收登录结果，复用已有 session/JWT 体系。理解流程不要求你亲手实现 JWT 密码学。
为什么需要它
你熟悉 JWT 后端，但这里要特别区分解码与验证。Base64 解开 payload 只能看见字段，任何人都能构造相似文本；可信认证需要验证签名和声明，再把 Apple 身份映射到业务账户。签名私钥、client secret 等服务端材料不能随 App 一起分发。
它是怎样工作的
后端应验证可信签名、预期发行方、受众、有效期与请求关联条件；授权码交换还需匹配对应应用配置。以经过验证的身份标识建立外部身份映射，不使用邮箱作为唯一不变身份。业务会话由自己的服务签发并管理过期、刷新和撤销，Apple 令牌不是所有业务 API 的通用 access token。
把关键概念连起来
验证身份
从 Apple 官方公钥验证签名，限制认可算法，并核对 issuer、与本客户端配置匹配的 audience、过期时间及绑定本次请求的 nonce。仅 Base64 解码 payload 不构成验证。
交换授权码
authorizationCode 短时有效且一次使用；服务端按实际流程向 Apple 交换令牌。client secret 由开发者私钥签名，只留在服务端，并管理有效期；不要把 Apple 私钥放进 App。
建立会话
以 provider + 经过验证的 subject（连同正确配置范围）映射内部 user_id，再发业务 session。用服务端保存的一次性 nonce 关联请求、校验后消费，Web 回调还要验证 state；提供退出与刷新策略。
沿用已有 Hono 后端
POST /auth/apple 接收本次授权结果与请求标识，服务端完成 Apple 验证，将可信 sub 映射到内部账号，再返回自己的会话。业务接口只依赖自己的鉴权层，不每次重新向 Apple 登录。
在 Hono 或 NestJS 后端落一条可信链
- 开始授权时保存短期请求关联信息，回调收到凭据后进行校验，拒绝不匹配受众与过期令牌。
- 按 provider 与经过验证的 subject 查找业务用户，首次创建使用事务或唯一约束防止并发重复开户。
- 签发自己的会话，把必要凭证安全保存，并让普通业务接口继续使用现有授权体系。
这里需要你亲自判断
不要把 identityToken 直接当作永久业务 access token；不要接受由客户端自报且没有绑定服务端请求的 nonce 校验结果。应用转移或分组还需按官方迁移规则处理身份。
做一个小练习
画出客户端、Apple、你的后端三个职责；给后端验证逻辑列出错误 aud、过期 token、错误 nonce 和重复授权码的测试。
- 为签名错误、aud 不匹配、过期和重复回调分别规定返回行为。
- 说明已有邮箱账号与 Apple 身份如何由已验证用户主动绑定，避免自动合并。
展开参考思路与验收标准
只有完整验证成功的身份才能进入映射步骤。邮箱相同不是自动合并账号的充分理由；回调重复到达也不应创建多个用户或无限追加会话。