第三方授权场景下一次性邮箱身份机制技术问询

方案落地现状、普及障碍与同类产品情况 #

你提到的「第三方专属身份标识+加盐邮箱别名」方案不是空想出来的概念，已经有实打实的落地：

• 目前落地最完整的是苹果的Sign in with Apple服务：默认向用户提供「隐藏真实邮箱」选项，会为每个接入的第三方应用分配唯一的中转邮箱别名，这类别名本质就是你提到的加盐标识，和用户真实邮箱没有可推导的关联，第三方只能拿到这个专属别名，既无法跨应用关联用户数据，一旦某个别名收到垃圾邮件，用户可以直接关停该别名的收信权限，精准定位泄露源，完全匹配你描述的SSO与邮箱服务能力协同的逻辑。
• Google自身也在近两年灰度了类似功能，用户授权第三方登录时可手动选择隐藏真实邮箱，由平台分配随机别名，但至今没有设为默认选项，普通用户感知极弱。
• 这套方案迟迟没有普及的原因说穿了就三个：
  • 第一是历史包袱太重：Google SSO是最早大规模普及的第三方登录服务，早期OAuth 2.0协议设计时根本没做身份标识与联系方式的分层，过去十几年接入的数百万第三方应用，几乎都把用户真实邮箱当自己账号体系的主键，一旦默认切断真实邮箱返回，海量存量应用的登录、账号关联逻辑直接就崩了，全生态的改造成本高到根本承担不起。
  • 第二是商业动力不足：跨平台用户身份关联是Google广告业务的核心能力之一，如果给所有第三方分配互不关联的专属身份标识，直接就断了跨平台归集用户画像的链路，和它自己的核心商业利益是冲突的，自然没动力强推。
  • 第三是用户心智惯性：Google早年推SSO的时候，打出来的核心心智就是「一个Gmail账号登遍全网」，现在反过来要打破这个心智，要花的用户教育成本高得离谱。
• 其他推出同类功能的身份服务商包括：微软在Entra ID（原Azure AD）中面向企业客户提供了专属身份标识配置能力，管理员可设置第三方应用无法获取用户真实邮箱；Auth0、Okta等面向B端的身份认证服务商，也早就支持为不同接入方分配独立用户ID、中转邮箱别名的功能，只是这类服务主要面向企业客户，C端普通用户很少接触到。

邮箱作为主身份标识的核心原因 #

邮箱成了全网通用的主身份标识，本质是互联网身份体系一路演化下来的路径依赖，根本不是什么技术上的最优解：

• 第一是邮箱最早实现了跨平台全局可达：在手机号实名认证、各家社交账号体系做起来之前，邮箱是唯一一个普通人能长期持有、不绑死在单一平台、能全球收验证消息的身份凭证，比起各个平台自己搞的容易重名的用户名，邮箱天然就是全局唯一的。
• 第二是开发者算过运维账：对做产品的人来说，邮箱是触达用户最稳的通道——用户可能换手机号、删App、注销社交账号，但只要邮箱还能收信，就能做账号找回、发安全通知，能少处理一大堆账号找不回来的客服工单，所以开发者天然愿意把邮箱当账号的核心主键。
• 第三是早期身份协议挖的坑：最早的OAuth、OpenID这些第三方登录协议做设计的时候，根本没考虑隐私分层，没把「身份校验凭证」和「用户联系方式」拆开，默认就把邮箱当可以公开的身份字段返给第三方，所有接入的开发者都顺着这个逻辑搭自己的账号系统，用的人越多路径依赖就越强，哪怕现在全行业都知道这里有隐私问题，也不可能短时间内把整个链路全改完。

现在行业其实已经在往身份解耦的方向走了，比如这两年开始推的通行密钥（Passkey），本质就是把身份校验凭证和邮箱、手机号这些能关联到个人的信息彻底剥离开，第三方只能拿到专属的校验标识，根本拿不到用户的真实联系方式，只是这类新方案要替换已经跑了二十多年的邮箱身份体系，还得熬很长的存量改造周期。

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