通过 Apple 登录：客户端在做什么
Sign in with Apple 让用户把 Apple 提供的身份声明交给你的应用。你仍需要决定业务账号和会话如何创建。
用你的前端经验理解
与接入第三方 OAuth/OIDC 登录类似：Apple 是身份提供方，你的应用与后端是使用身份的一方。它不会自动同步 iCloud 数据。
为什么需要它
“通过 Apple 登录”让用户用 Apple 身份进入你的产品，但最终仍需要映射成你自己的业务用户。客户端的主要工作是发起系统授权、接收结果，并把必要凭据送到可信后端。不能把回调中的 user 字符串直接发送给接口就当作认证完成，因为普通客户端输入本身不可信。
它是怎样工作的
授权结果中的身份令牌、授权码和资料承担不同职责。身份令牌用于验证声明，授权码用于服务端交换，姓名等资料应在首次可用时妥善保存，后续登录不能假定再次返回。请求与回调需要绑定，nonce 等关联值应来自安全随机流程，服务端校验必须与发起时约定一致。
把关键概念连起来
工程与入口
配置 App ID 的 Sign in with Apple 能力、签名及对应 Target；使用 AuthenticationServices 和官方按钮。Web 接入还需要 Services ID、已配置的域名与返回 URL。
请求与返回
按需请求姓名/邮箱，处理成功、取消和失败。ASAuthorizationAppleIDCredential 可能包含 user、identityToken、authorizationCode，以及首次授权的资料。不要把客户端回调当成服务端验证。
资料与身份
姓名等初始资料通常只在首次授权提供，应在验证和创建账号流程中妥善保存，缺失时不要清空已有资料。邮箱可为私密转发地址；身份映射应基于已验证的稳定 subject 与应用/开发者配置范围。
首次登录和再次登录
第一次：验证身份后创建 user_123，保存用户允许提供的资料。第二次：按同一已验证 subject 找到 user_123；即便姓名为空，也继续使用原资料。用户主动编辑资料是另一条流程。
首次登录与后续登录分别处理
- 用户点击系统登录按钮后创建一次授权请求，避免在 body 更新或页面出现时自动发起多次登录。
- 授权成功后把凭据交给后端，只有后端返回业务会话后才进入已登录页面；用户取消属于正常结束。
- 后续登录没有姓名时读取已有业务资料，不覆盖成空值，也不因为资料缺失新建第二个账号。
这里需要你亲自判断
不要用邮箱自动合并两份业务账号；再次登录拿不到姓名并不一定是错误。iCloud 账号、商店购买账号和你的业务账号不能直接画等号。
做一个小练习
用真实测试工程分别验证首次授权、再次登录、隐藏邮箱与取消；记录字段是否存在，不记录令牌内容。
- 列出取消、授权错误、后端验证失败与会话成功四条路径。
- 模拟第二次登录缺少姓名，确认账号与原有文章仍正确关联。
展开参考思路与验收标准
客户端授权成功只是流程中间结果。业务用户 ID 应由后端返回，昵称、邮箱等展示资料不应成为登录可信性的判断依据。