应分别检查账户登录、数据访问授权和聊天密钥恢复；一个登录按钮不能回答这三个问题。
“使用 Google 登录”既不自动意味着 Google 能读取聊天正文，也不是无需付出信任代价的选择。这种方式将身份提供商引入登录过程；应根据权限和服务的实际设计，检查传输的信息及账户依赖关系。
做决定时，请把账户登录、访问 Google 数据的授权和对话加密密钥分开考虑。一个登录按钮并不能回答这三个问题。
OAuth 与 OpenID Connect 有何区别？
OAuth 是用于授予资源访问权限的框架。OpenID Connect 在其上提供身份验证层。Google 登录文档说明了用于识别用户、基于 OpenID Connect 的流程。
因此，“OAuth 会把 Google 密码交给即时通信应用”的说法并不正确。服务必须正确验证相关令牌，并保护自己的会话。Gmail、Drive 或其他数据的授权，与单纯登录是不同的事。权限与 scope 的说明。
可能交换哪些信息？
登录流程通常向服务提供一个标识符，以及根据权限提供的电子邮箱或个人资料等信息。身份提供商也参与身份验证相关请求。但不能从登录方式的名称推断，每次打开应用、每条消息或全部使用历史都会发送给该提供商。
| 问题 | 应检查的内容 |
|---|---|
| 即时通信应用获取哪些账户信息？ | 同意页面、scope 和隐私政策 |
| 是否请求了额外的数据权限？ | 登录与访问邮件、文件或联系人的区别 |
| 身份提供商何时再次参与？ | 具体实现的会话策略和令牌刷新机制 |
| 聊天密钥是否依赖此登录？ | 密钥存储和恢复文档，而非仅看登录按钮 |
不要授予无法解释为何符合你需求的权限。同时，也不要未经检查就把某项具体的权限请求解读为“读取所有消息”。
依赖中心账户有什么风险？
如果你登录某个即时通信应用的唯一方式，是一个后来无法访问的账户，那么新的登录可能受阻。对现有会话、本地数据和恢复的影响取决于服务设计。因此，“Google 账户被封就一定会毁掉所有聊天”不是正确结论。
在发生紧急情况之前，检查服务是否提供替代登录方式或恢复流程，以及添加它会如何影响账户安全。备用方式不应成为攻击者更容易利用的途径。也不要在尚未确认下一次如何登录时更改或移除账户关联。
使用 SRP 直接登录能消除所有这些风险吗？
直接登录可以减少对第三方身份提供商的依赖。正确实现的 SRP 也能在不通过协议消息发送密码本身的情况下，证明知道密码。但即时通信服务仍会处理账户名称、登录事件及相关运行数据；“没有数字足迹”并不是准确描述。
存储的 SRP 验证值也必须受到保护。RFC 5054指出 verifier 泄露后密码被猜测的风险。登录页面、会话、恢复和设备的安全仍然必不可少。
没有任何技术原则规定 SRP 是唯一保护隐私的登录方式，也没有原则规定所有联合登录都天生不安全。决定性因素应是实现质量和威胁模型。
Livara 声明的边界
Livara 安全页面描述了用于身份验证的 SRP，也明确说明会保留某些运行数据。这并不意味着账户身份对服务本身是隐藏的。同一页面也将加密身份恢复与聊天历史区分开来。
要进行实用的比较，请要求每项服务回答相同的问题：获取什么数据，涉及哪些第三方，如何终止会话，以及如何恢复聊天密钥？有文档支持的答案比“零知识”口号更有用。
选择登录方式之前
保护好主账户和恢复途径，阅读请求的权限，检查关联设备，并了解失去账户访问权时的应对方案。然后选择符合自身需求和管理能力的登录方式；便利与独立都有价值，但任何一项本身都不是安全保证。
