如何使用 OAuth2 身份验证保护私有数据？

Question

我正在建立一个网站以使用 Google 的 OAuth2 界面进行用户身份验证。该网站将存储与每个用户相关的私人数据——我打算对其进行加密。

如果我为网站实施了自己的身份验证方法，我可以轻松地从用户的凭据（包括用户的密码）中派生出一个密钥，从而为每个用户的数据提供强有力的保护。但是使用 OAuth2，我相信我只能收到一个访问令牌，在一段时间内授予该用户权限 - 问题是访问令牌值会随着时间而变化。

OAuth2 有没有一种方法可以为我提供与用户相关的不可变机密，我可以使用该机密从中派生安全密钥？还是有其他使用 OAuth2 创建安全持久密钥的方法？

--- 编辑---

针对问题和 cmets，以下是一些需要考虑的想法：

• 应始终使用强加密和用户身份验证来保护所有用户信息 - 我们阅读如此多有关网站和数据库黑客攻击的新闻文章的原因是因为开发人员说“我们真的需要保护它吗”然后回答“不 -因为除了我们之外没有人可以访问数据库，安全性很困难等等”。黑客下载了数据库et violá。信用卡、电子邮件地址、电话号码、密码，随便你说出来，然后就被泄露了。
• 只有两个真正的秘密 - 一个是存储在某人头脑中的密码，另一个是只有授权用户才能访问的强随机值（如物理令牌）。如果您认为安全密钥可以仅从电子邮件地址派生，或者需要将机密存储在数据库中，那么您并不真正了解安全性。

我想我试图发现的是 OAuth 提供者是否可以向 OAuth 客户端提供安全链接到用户和客户端的不可变值 - 实际上，这将是一个只能由 OAuth 提供者使用解锁的密钥用户密码（他们的身份验证密码）和客户端密码（在 OAuth 协议中使用）的组合。然后，客户端可以使用此值为用户数据提供合理的安全级别。

当然，这种实施并非完美无缺，但实施得当，可以提供一种合理的方式来保护数据，同时仍然使用 OAuth 方案的良好做法。

Answer 1

令牌的意义在于您可以使用令牌从 Google 获取有关用户的信息。在初始身份验证期间，您将告诉用户和谷歌您想要访问有关用户的某些信息：

https://developers.google.com/+/api/oauth

假设用户允许您访问他们的信息，例如他们的电子邮件地址，那么您就可以从 google 获取他们的电子邮件地址。获得他们的电子邮件地址后，您可以为他们的用户生成一个密钥，将其存储在您的用户表中，并使用它来加密他们的数据。然后，当他们再次登录时，您可以查找他们的电子邮件地址并找到他们的密钥。

对于不可变信息是否特别需要“保密”？还是只是识别用户的钥匙？

如果您要存储的信息是真正的私密信息，并且您希望将其设置为无法访问用户的数据，那么您所要做的就是为您的用户存储加密的 blob。一旦用户下载了他们的数据，他们就可以使用他们的密钥在客户端解密数据。

Answer 2

我的第一个问题是：为什么要从某些令牌中派生加密密钥？

令牌和您的加密密钥可以保持独立，并且可以与由唯一 ID 标识的用户相关联。用户身份验证可以通过您需要的任何方式通过凭据或开放 ID 身份验证或其他方式完成。但是，一旦用户通过身份验证，您的解密 API 就可以获取与经过身份验证的用户关联的解密密钥，并执行它必须执行的任何解密操作。

通过这种方式，您可以潜在地允许用户将多个开放 ID 帐户与同一个用户绑定，类似于 Stackoverflow 的做法。我可以将我的 yahoo、facebook 和 google 帐户与我的 Stackoverflow 用户相关联，并且可以使用这些提供商中的任何一个登录。我可以随时取消关联这些帐户。但这不会影响我的 Stackoverflow 个人资料和数据。

因此，从非恒定且不断变化的事物中派生密钥并不是一个好主意。相反，请将它们分开。

Answer 3

如果我为网站实现了自己的身份验证方法，我可以轻松地从用户的凭据中获取密钥

此架构有一个可怕的弱点 - 如果用户忘记/重置其凭据，则密钥将永远丢失

OAuth2 有没有一种方法可以为我提供与用户相关的不可变机密，我可以使用该机密从中派生安全密钥？

OAuth2 是一种授权协议。它无意向您提供任何用户机密。

Google 的 OAuth2 应该提供一个 user info service 返回用户名（电子邮件）和一些 ID（子）。

但是，这些是身份信息，而不是任何秘密。并且混合用户凭据是恕我直言的坏主意（如前所述），使用外部 IdP（谷歌）您将无法访问凭据。

现在呢？

我的建议：

如果您确实想使用用户提供的密钥来加密用户的数据，请让用户提供密钥或由用户自己（或使用用户的公钥？）加密数据加密密钥。用户必须知道，如果这个秘密丢失，数据将无法访问。从长远来看，它是安静的不舒服。一些 DMS 系统使用这种方法来加密存储的敏感文档。

如果您想加密静态数据（在服务器、数据库上），您可能有一个特定于应用程序的密钥，恕我直言，最好存储在其他地方（密钥库、密钥管理服务......）。确实存在不同的风险概况（您必须保护密钥，..），但对用户来说更方便。这通常与其他安全措施相辅相成（即使是大企业也不会要求单独的密码来加密您的信用卡号或电子邮件）

Answer 4

您需要的是每个用户的恒定安全（随机）密钥，您可以从提供 OAuth2 端点的身份验证服务（在本例中为 Google）获得。

OAuth2 协议本身不提供此类值 - 身份验证服务器使用生成的非恒定值。但 OAuth2 并不禁止从资源服务器（连同用户 ID、电子邮件等）提供此值。所以基本上 OAuth2 可以让您以您想要的方式保护数据，但是您目前使用的 Google 并没有提供这种类型的恒定随机值。

另请注意，如果您让用户关联少数帐户（如 Google 和 Facebook），这将不起作用，因为它们会提供不同的随机密钥。

如果您从凭据中获取秘密，这也意味着重置密码将重置用户帐户。

此外，如果您以这种方式加密电子邮件等数据，则在当前没有登录用户的情况下无法解密它们。因此，通过电子邮件发送时事通讯几乎是不可能的。您也不能在 SQL 中查询数据。

我只能提出一些对策：

• 根本不存储敏感数据，或将其存储为散列。密码必须经过哈希处理，而不是加密。不要存储 CC 编号，存储代表它们的令牌。
• 使用密钥加密，存储在另一个数据源中。这至少增加了一些安全性 - 攻击者不仅必须获得数据库副本，还必须获得加密密钥。
• 由于数据已加密，因此不再需要将其存储在数据库中。您可以将加密数据存储在文件或其他来源中，这样比在数据库中更安全（没有 SQL 注入等风险）

Answer 5

我也遇到了同样的问题。到目前为止，我找不到安全的解决方法。

基本上，我们需要每个站点随机生成的秘密，仅提供隐式流，可用于派生凭据以访问系统和解密数据。

因为我想保护自己的数据，我可以通过两种方式编写客户端来对密钥进行加盐/哈希处理，一种是检索数据，另一种是解密。

唉，事实并非如此。

我可以从 oAuth 的基本范围内的事物中获取凭据，这将保护数据免受 me 的侵害，但这会使用户容易受到跨站点漏洞的影响，此外，还可以识别个人身份信息是一个糟糕的秘密。

我得到的最好方法是使用隐式流 oAuth2 获取用户的电子邮件地址，随机生成客户端密钥，并强制用户通过电子邮件将密钥发送给自己（作为恢复密钥），然后将密钥存储在 localStorage 中。对 secret + oauth 范围变量加盐/哈希，以派生访问、加密和解密数据所需的凭据客户端（因此用户必须登录）。

如果用户清除了他们的 localStorage，他们需要点击恢复电子邮件中的链接，这会将秘密放回 localStorage。

这将漏洞的范围放回客户端，但对公共机器有抵抗力（必须知道谁最后登录，并获得对 localStorage 令牌的访问权限），允许恢复，并且弱要求用户已登录。仍然容易受到插件注入攻击和物理访问 + 了解用户。

更新：我决定使用一些 oAuth 扩展（hello.js、文件夹 API）将用户帐户中的密钥作为文件存储。它需要一些权限和一些 API 才能实现，但似乎是可行的。