PHP 中的工作流 OAuth 1.0a答案

【问题标题】：Workflow OAuth 1.0a in PHPPHP 中的工作流 OAuth 1.0a
【发布时间】：2014-04-03 20:41:23
【问题描述】：

我已经尝试了解 OAuth 有一段时间了，但我仍然对工作流程和处理所用值的建议有一些疑问。我正在开发一个 PHP 三足 OAuth 1.0a 项目以供学习。这里描述了我将要提到的步骤； http://wiki.oauth.net/w/page/12238555/Signed%20Callback%20URLs

为什么在第 5 步中返回了一个令牌？我认为令牌已经为消费者所知，就像 token_secret 一样。所以它用作关于消费者发送数据的请求的标识符？还是我误以为发送的令牌与步骤 2 中发送的请求令牌相同？
回调 URL 在这里被列为可选，但在其他规范中它被认为是必需的。我正在考虑让人们将他们的回调 URL 存储在服务提供商的数据库中，因为它不会经常更改或根本不会更改，因此不会在步骤 1 中发送它并在步骤 5 中从数据库中检索它。
由于速度和可能的泄漏，不鼓励使用 RSA 哈希方法，因此每个人都决定使用 HMAC 方法。那么我们是否需要在步骤 1 和 6 中发送散列方法？此外，我看到很少有服务提供商提供其他方法。
使用 mt_rand() 制作哈希并不安全，所以我在考虑使用 openssl_random_pseudo_bytes()，它是否安全，例如作为 hash_hmac() 的哈希键？
我经常看到 sha1 用于请求和访问令牌以及 secret_tokens。像 sha256 或 sha512 这样的较长哈希不是更安全吗？如果安全延伸到存储空间，应该不是问题吧？

【问题讨论】：

标签： php security oauth

【解决方案1】：

即使消费者知道令牌，您也必须知道返回的用户在哪个 OAuth 会话上进行操作。在此步骤中，令牌充当会话标识符。否则你怎么知道返回的用户是谁（除非你自己在回调中提供会话标识符）。
我建议您遵守规范。由于如果您充当服务提供者，则无法控制消费者，因此您对回调要求一无所知。如果它是动态的（例如，包括 1. 中的会话标识符），您将遇到存储回调的问题。
再次。坚持规范。尽管它不是一成不变的，但许多聪明人一直在努力研究它，并长期认真地思考规范更改的含义。由于一个人可能无法同时控制两个域（服务提供者和消费者），因此您必须就身份验证方法达成一致。如果域不知道该方法，它们如何知道如何解释密码？如果当前的方法被认为不安全怎么办？如何查明一方是否改变了方法？
这个函数应该是加密安全的。你可以使用它。
当然，您可以使用更强的哈希。你可能应该。确保两个域都理解该方法。见http://oauth.net/core/1.0/#anchor45

【讨论】：