Apple Sign-In未签名user参数的安全性与信任验证问询

核心验证逻辑：绑定id_token确保请求合法性 #

虽然user参数本身未签名，但它是和Apple授权服务器返回的id_token、code、state一同返回的，你可以通过以下步骤确保user参数的可信性：

• 验证id_token的签名：使用Apple的公钥验证id_token的签名，确认它确实由Apple签发且未被篡改。这一步能保证请求来源是合法的Apple授权流程。
• 验证state参数：确认返回的state和你发起授权请求时生成的随机值一致，防止CSRF攻击。
• 绑定sub唯一标识：将user参数中的信息与id_token解码后的sub（用户唯一ID）绑定存储。后续通过code调用/auth/token接口换取令牌时，返回的sub必须和首次的sub一致，进一步确认用户身份的一致性。

攻击者无法伪造出匹配合法sub的user参数，因为他们无法获取Apple签发的对应id_token——只有完成合法授权流程的请求，才能同时拿到有效的id_token和对应的user信息。

姓名信息的处理建议 #

• 仅首次授权返回：Apple只在用户首次授权你的应用时返回姓名信息，后续登录不会再提供，所以你必须在首次拿到后立即与sub绑定持久化存储。
• 关于篡改风险：如果用户在回调过程中自行篡改user里的姓名，这属于用户主动提交虚假信息，而非第三方攻击。这种情况下，你可以在业务逻辑中说明姓名信息来自Apple首次授权，后续允许用户在你的系统内自行修改（毕竟Apple不会再提供验证渠道）。

邮箱信息的可信性保障 #

id_token中包含签名的email和email_verified字段，你可以直接信任这两个字段的真实性，无需依赖user参数中的邮箱信息。

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