三个月前，我取消了社交登录，解雇了 Auth0，并决定使用 Magic Links（在Phoenix很容易 – 你好mix phx.gen.auth ）。
在实现了自己的 Facebook 和 Google 社交账号登录功能后，我决定采用 Auth0，因为除了传统的用户名/密码之外，我还想支持 GitHub。我曾设想过如何利用 Auth0 来管理权限，并通过实现中间件来执行其“操作”，创建引导用户访问的流程，但最重要的是安全性。我不想涉足密码和令牌的管理，而是想专注于增值功能，也就是用户付费的功能。
但一年后，我却改变了主意，原因如下。这些原因不分先后。
- 85% 的用户都使用常规的邮箱/密码登录，所以额外的登录选项只会让他们感到困惑。我原本想简化用户操作，以为添加社交账号登录就能降低注册门槛。但事实证明，我的想法是错误的。
- 人们误用他们常用的邮箱/密码组合登录社交账号，而他们自己也拥有这些社交账号，这给管理带来了混乱，尤其从客户支持的角度来看。
- 我无需管理来自 Meta、Google 等平台的密钥，例如策略更新、令牌过期，以及其他随机的“必需操作”，这些操作都会在 Meta 开发者门户中抛给我，而每个页面都需要 20 秒才能加载。
- 我高估了实施自己的安全系统需要多少工作量，但 Phoenix 1.8 让实施 Magic Links 变得非常简单，在 Claude 的帮助下，整个过程只用了一个周末就从零开始投入生产。
- 我喜欢将身份验证外包给用户的电子邮件服务提供商（通常是 Gmail）的想法，让它成为整个安全链中最薄弱的环节。他们一直在考虑这些问题，所以我无需操心。他们实际上已经为我实现了多因素身份验证 (MFA)。
- 我不想承担不必要的费用。虽然我加入了Auth0的“创业计划”，但他们随时可能提高费用，我不喜欢这种不确定性。我创业资金有限。
- 在一个独立的系统中管理权限太复杂了。我使用的是基于角色的访问控制 (RBAC)，实现起来并不难，但仅仅为了查看“该用户是否拥有访问权限？”就跨越网络和系统边界，感觉有点杀鸡用牛刀。我确实通过一个操作将所有权限都写入了 JWT，但任何权限更新都需要重新获取这些信息，而我的用户经常更新权限。同步状态的工作量太大，感觉完全没必要这么复杂。
- 使用 Elixir 的LetMe 库实现基于资源的授权变得简单得多。只需提供一个数据库，然后通过 API 调用进行查询——简直太方便了。由于避免了 REST 调用，在 LiveView 中实现管理 UI 也更加流畅。
- 使用 Auth0 的通用登录功能时，对登录界面的自定义控制非常有限。我知道登录界面必须简洁，但添加一些其他链接都很难。仅仅能够自定义品牌标识是不够的。
- 很多用户对重定向到“另一个”网站感到困惑，尽管我使用的是自定义域名。老用户看到网站头部发生变化时，还以为自己做错了什么。
- 我实现了账户欺骗功能，但过程很麻烦，因为我无法直接从 Auth0 解密令牌，他们不提供解密密钥（我想他们这样做也无可厚非）。我为运维人员设计了一个非常奇特的变通方案，让他们可以通过欺骗来解决客户问题。我的实现方式本可以更好，但目前的代码复杂度仍然过高。
- 我讨厌 Meta 和 Google，我希望引导我的用户远离它们，而不是靠近它们。
- 我当时觉得，只要采取正确的系统管理、存储和加密措施，就能确保客户数据的安全，把这些信息外包给外部供应商并不会带来任何额外的安全保障。我高估了管理这项工作的复杂性（但愿如此）。我觉得，拥有一个优秀的云服务和存储供应商比拥有一个优秀的身份管理供应商更重要。
总而言之，我从整个过程中学到了很多，Auth0 的确在我刚好启动 Phoenix 1.8 版本之前的项目时帮了我很大的忙。或许这只是 Elixir/Phoenix 让开发变得轻松愉快的又一个例子，而不是对使用身份提供商的控诉。