是的他们可以。

简单的答案：您以某种方式向身份提供者进行身份验证，通常是通过用户名和密码。糟糕的管理员可以存储传输的凭据并重新使用它们。这种攻击不依赖于后端的实现方式。

通常，您的身份提供者的密码根本不用于对第三方服务的身份验证，这意味着您的身份提供者实际上拥有您的登录密钥（而您根本没有它们）。

您可以考虑将您的密码合并到身份验证过程中而不在之后将其未加密存储的方案，但实际上我不知道任何此类方案。

TL;DR：可以欺骗您的 Facebook 登录名的糟糕 Facebook 管理员可以在 Facebook 上以您的名义发布不良内容，这通常被认为比在 Stack Exchange 上发布问题更糟糕。

我更详细的答案集中在OAuth 2.0上，它是此用例的行业标准，并且是 OP ¹中 Google 授权草图的背后。

OAuth 2.0 框架最初不仅仅用于身份验证，而是用于更一般的授权用例：服务 A 想要访问服务 B 上用户拥有的某些资源。

例如，用户在服务 A（照片编辑应用程序）和服务 B（Google Drive）上都有一个帐户。使用 OAuth 2.0，用户授予应用程序访问其在 Goole Drive 上的照片的权限。一些注意点：

• 服务 A 需要是服务 B 上的注册应用程序：在示例中，开发人员必须在Google Developer上注册她的照片编辑应用程序。在启动授权流程时，服务 A 通过客户端 ID 和客户端密码（如果是服务器端流程）或客户端 ID 和主机名（如果是客户端流程）向服务 B 标识自己。
• 服务 A 将用户重定向到服务 B 的授权端点，用户只需在服务 B 上输入其服务 B 的凭据。服务 A 不能欺骗服务 B 的登录，因为它不控制授权端点。服务 B 不能欺骗服务 A 的登录，因为它不是由用户提供的。
• 服务 A 可以用来访问用户在服务 B 上的资源的最终令牌响应带有一个范围。服务 B 将让服务 A 仅访问授权范围内的资源。范围会在用户重定向到的授权窗口中向用户解释。在该示例中，来自 Google Drive 的授权窗口将解释诸如“此照片编辑应用程序可以查看和修改您在 Drive 上的照片”之类的内容。然后，Google 将允许该应用访问照片，但不允许在 Google Plus 上发布任何内容，因为它不在授权范围内。

第三方登录是一种非常常见的特殊情况，用户拥有的资源是他们在服务 B 上的基本帐户信息。开发人员没有要求用户在她的服务上注册，而是选择让谷歌验证用户的身份.

该系统仅在以下情况下工作

1. 服务 A 信任服务 B
2. 用户信任服务 B

好消息是用户不必信任服务 A。

但是，如果用户比服务 B 更信任服务 A，则他们不应使用第三方登录并在服务 A 上注册（当该选项可用时）。

^{1 个原始帖子}

是的他们可以。马里奥已经解释了它在技术上是如何工作的。我将在这里专注于信任部分。

无论您在计算机上执行什么操作都意味着信任。您信任系统和手机的操作系统编辑器。您信任安装在其上的任何程序的所有编辑器。您信任您使用的任何在线服务。而且您相信您的银行不会对您的帐户做任何事情（这超出了信息学...）。

但是在信任级别上有一些程度。我相信航班预订系统足以给他们买东西，但我不相信他们提供我的银行凭证。无论如何，我足够信任我的密码保险库程序。

因此，在信任链中，重要的是：链中的一个参与者是否只应获得比整体行动更低的信任级别？使用 Facebook 帐户进行 SO 可能很好，攻击风险和可能的后果与我对 Facebook 的信任兼容恕我直言。但我永远不会为我的银行使用 Facebook 帐户（他们反正也不提供）。当然，信任一个系统意味着信任它的任何管理员。

是的。这就是为什么有可用的技术使这成为不可能的原因（例如基于隐私保护的基于属性的凭据），但到目前为止，它被认为对于普通用户来说太不切实际了（而且我不知道有任何软件具有合理的可用性并且零浏览器支持）。这项技术不允许他们冒充您，甚至更多，因此无需连接到中央提供商即可完成登录。（当前方法的问题是您将正在使用的站点泄露给身份提供者）。