如何通过第三方 API 安全地维护用户身份验证？答案

【问题标题】：How to securely maintain user authentication through a third party API?如何通过第三方 API 安全地维护用户身份验证？
【发布时间】：2011-06-23 16:00:01
【问题描述】：

我正在构建一个允许用户创建、编辑和保存文档的 web 应用程序。用户帐户的数据库是单独控制的，我已经获得了一个 SOAP API，它将告诉我给定的用户名/密码是否有效。

假设用户名/密码有效，API 将返回以下信息：
• 电子邮件地址
• 用户名
• login_number（帐户的唯一 ID，似乎是一个自增整数）

我会将我的应用程序的数据存储在我自己的数据库中，因此我可能会使用 login_number 将数据绑定到各个用户。

我的问题是，一旦用户成功登录，我应该如何跟踪用户。将 login_number 存储为 cookie 是可行的，但对我来说似乎非常不安全。我正在考虑类似于存储某种随机散列的 cookie 以及存储该散列和相关联的 login_number 的查找表，但我不确定这是否足够。

用 PHP/MySQL 标记，因为这是我计划使用的后端，但不确定它对这个问题真的很重要。

【问题讨论】：

标签： php mysql api web-applications authentication

【解决方案1】：

这在任何开放式身份验证中都很常见，例如 Facebook oAuth 2.0。一旦用户同意您的条款，Facebook 就会提供他的用户 ID、电子邮件以及一种随时检查用户是否仍处于登录状态的方法。

所以，有几种方法：

依赖提供者：如果基于 User-Id，SOAP API 提供用户是否登录的信息。您可以在执行任何需要身份验证的任务之前使用此调用。
在 SOAP API 之上构建您自己的身份验证：我猜这就是您打算做的事情。该方法是使用加密/散列且难以重新创建的令牌。
这个想法是这样的

(a)一旦用户登录创建一个唯一的令牌，将此令牌保存在用户的会话或某个永久存储中。可能在内存缓存中或与 userId 映射的某个地方。基本上，无论您在何处检索此令牌，您都知道与哪个用户相关联。

(b) 将此令牌存储为 cookie。

(c) 每当您要进行身份验证时，请使用cookie 中的令牌以与用户会话中保存的令牌匹配（或提取与令牌匹配的 userId，并将当前 userId 与使用令牌提取的 userId 匹配以进行验证）。

(d) 在注销时删除 cookie。

现在，man-in-the middle 很有可能通过这种方法附加。

一种方法很昂贵，即在每个请求结束时更改令牌。这并不能消除 MITM 攻击，但攻击的机会相当渺茫。

希望这会有所帮助。

Nonce nonce 的概念很简单，也很扎实。但我不确定它是否适用于您的情况。它基本上是为了保护 SOAP 调用。 AWS 使用类似的东西。

为客户提供secretKey。
每当 cient 发出请求时，他都必须传递带有 secretKey（比如 token）的当前时间戳的哈希值以及它用来创建 token 的时间戳。
服务器通过将token 与服务器使用在标头中传递的时间戳创建的哈希值进行比较来验证token，而secretKey 存储在服务器端的其他位置，可能作为密码或secretKey 在数据库中。
如果令牌匹配，则允许用户访问，否则不允许。
还有一件事，如果时间戳与服务器当前的时间戳相差太大，服务器也可能会禁止访问。

这种方法实际上不受 MITM 攻击，但不确定这是否最适合您。

客户端服务器对话如下所示

client ----request timestamp                           --------> server 
       <---current timestamp                           -----------'
--- {ts: timestamp, token: Hash256(timestamp, secretKey)} --> isEqual(token, hash256(ts, secretKey))
                                                              |   |
                                        Access Denied<- false/   true --> ACCESS

@kramthegram 感谢提醒 Nonce

【讨论】：

只要你不重复随机数并且每次请求都改变它，改变随机数就可以防止中间人攻击。我认为在注销时更改就足够了。

【解决方案2】：

您可以尝试使用基于会话的nonce 对用户编号进行哈希处理。将该 cookie 设置为在登录超时长度（比如 30 分钟）后过期。每个会话的随机数将有助于防止恶意用户复制您的 cookie 以获得访问权限的播放攻击，因为每个会话都有时间敏感的哈希值。

【讨论】：