基于Azure B2C的Xamarin应用认证：用户数据存储与唯一标识咨询

我来帮你梳理下这个问题的最佳实践，结合Azure B2C的设计初衷和应用开发的常见场景来看：

数据存储选择：地址和头像该放哪儿？ #

首先得明确Azure B2C的定位：它是身份管理服务，核心职责是处理用户认证、身份信息的基础存储，而不是业务数据仓库。基于这个定位，我们可以这样区分：

• 地址：

  • 如果只是用户的基础联系地址（比如用于身份验证相关的通信），可以考虑存在Azure B2C的自定义用户属性里，这样在用户登录获取令牌时就能一并拿到这个信息，不用额外调用应用数据库。
  • 但如果是应用内的业务相关地址（比如多个收货地址、和订单绑定的地址），或者需要频繁修改、和其他业务数据关联的地址，一定要存在应用数据库里。B2C的用户属性设计不是为了支持复杂的业务数据操作，强行存储会增加后续维护的复杂度。

• 头像：

  • Azure B2C不支持直接存储图片二进制文件，只能存URL。所以常规做法是把头像上传到Azure Blob Storage这类对象存储服务，然后把URL存起来。
  • 如果希望在用户登录时就能通过身份令牌获取头像URL，把URL存在B2C的自定义属性里会更方便；如果头像和应用内的其他用户业务数据（比如用户偏好、动态信息）关联紧密，存在应用数据库会更灵活，方便后续扩展。

用户唯一标识符：选userId（objectId）还是邮箱？ #

绝对优先选择Azure B2C提供的objectId（也就是你说的userId），而不是邮箱，原因有这几点：

• 稳定性：objectId是B2C中用户的永久唯一标识符，一旦创建就不会改变。而邮箱是用户可以修改的，要是用户换了邮箱，用邮箱作为关联键会导致应用数据库和B2C的用户关联断裂。
• 兼容性：如果后续支持第三方登录（比如Google、Facebook），有些用户可能不会提供邮箱，或者不同身份提供商的邮箱可能重复，但objectId始终是唯一的，能保证跨登录方式的用户关联一致性。
• 安全性：用objectId作为应用数据库的用户外键，避免了把邮箱这类敏感信息作为关联键暴露在业务逻辑中，降低了数据泄露的风险。

额外的实践小贴士 #

• 如果你选择在B2C中存储自定义属性（比如地址、头像URL），要注意B2C的自定义属性有数量配额，而且修改这些属性需要调用Microsoft Graph API，要提前规划好权限和调用逻辑。
• 建议采用**身份数据（B2C）+ 业务数据（应用数据库）**的分离模式：B2C管登录、基础身份信息（姓名、邮箱），应用数据库管业务相关的用户数据（地址、头像URL、应用内偏好等），职责清晰，维护起来更省心。
• 用户登录后，从B2C的令牌中提取objectId，再用这个ID去应用数据库查询对应的业务数据，这是最稳妥的关联方式。

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