.NET应用通过外部登录提供商获取的邮箱是否需要额外确认？

邮箱被篡改的风险说明 #

只要你是走标准OAuth 2.0/OpenID Connect流程对接，使用.NET官方的Microsoft.AspNetCore.Authentication.Facebook包实现登录逻辑，完全不用担心传输中途被篡改邮箱的问题。
你拿到的用户身份信息要么是带Facebook数字签名的ID Token，要么是通过官方HTTPS接口拉取的加密响应，官方中间件默认已经做了签名校验、重放攻击防护、响应完整性校验，中间人就算篡改了传输内容，校验会直接失败，你根本拿不到被篡改的邮箱数据。

当前流程的合理性判断 #

你现在的做法是不是最佳实践，完全取决于你的业务场景：

• 如果你的平台不支持邮箱+密码登录，所有用户只能通过第三方账号登录，那这个流程就是行业通用的最佳实践。你自己使用第三方登录时从未遇到过二次验证邮箱的情况，就是因为绝大多数平台都是这么做的：第三方登录提供商已经帮你完成了邮箱归属校验，你完全没必要多增加步骤破坏体验，违背简化登录流程的初衷。
• 只有当你后续允许用户解绑第三方登录、用邮箱+密码独立登录，或者要做同邮箱的多账号合并功能时，直接默认邮箱已验证才会有极低概率的风险：比如用户Facebook绑定的是其他人之前弃用的邮箱，原邮箱持有人已经在你平台用该邮箱注册过密码账号，后续合并账号时可能出现权属纠纷，但这种场景非常少见。

你看到的教程要求发确认邮件，本质是覆盖所有场景的通用安全兜底方案，不管你支不支持密码登录都不会出错，但显然不符合纯第三方登录场景的体验需求，完全没必要照搬。

推荐的最佳处理流程 #

• 授权回调后优先校验身份响应的合法性，这一步.NET官方认证中间件已经默认实现，只要你没有手动关闭校验逻辑就不需要额外开发
• 不要用邮箱作为第三方账号的匹配依据，必须用Facebook返回的唯一OpenID作为匹配键：用户可能修改Facebook绑定的邮箱，但OpenID是永久不变的，用邮箱匹配会导致用户改邮箱后找不到自己的账号
• 匹配到已经绑定该OpenID的老账号：直接完成登录，若Facebook返回的最新邮箱和你库中存储的不一致，可以后台静默更新，不需要打扰用户
• 未匹配到老账号：用Facebook返回的公开信息（邮箱、昵称、头像等）直接创建新账号，默认标记邮箱为已验证，直接完成登录
• 可选安全补充：如果你的平台后续支持用户设置密码、解绑第三方登录，只需要在用户第一次触发这些操作的时候，再发验证邮件确认邮箱归属即可，不要放到注册登录环节增加用户阻力

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