1

背景：我正在尝试创建 SMS API 服务。开发人员有一个 Dev ID，以及分配给他们的开发人员帐户的 API 密钥。开发人员将创建将调用我的 API 的应用程序。但必须首先验证发出调用的应用程序。

问题：我遇到的主要问题是身份验证。我阅读了 OAuth 并且非常了解它。我通读了这个演示文稿（幻灯片 71-82）。所有 OAuth 文章都在谈论 OAuth 的“舞蹈”或“三角恋”。我的问题似乎是，在我的情况下我没有看到合适的三角形。或者，更好的说法是，三角形似乎并不完整。

我的意思是，假设 LinkedIn 试图制作一些应用程序来帮助用户将他们的 LinkedIn acc 与 twitter 关联起来，OAuth 是完全有意义的。因为LinkedIn需要代表用户从twitter获取资源（因为用户有一个推特账户）。在我的情况下，只有消费者拥有在我的服务中注册的开发者帐户。最终用户没有任何凭据可供消费者代表询问。那么我该如何实现 Oauth？那么消费者会问供应商什么呢？它只会说“小心，我来了？”。因为这似乎毫无意义，除非它要求请求令牌以换取访问令牌。但在这种情况下，由于最终用户甚至没有帐户，因此这些步骤似乎毫无用处。

所以，我不知道如何解决这个身份验证问题。我尝试过考虑使用 php 会话，这样它可以帮助我将令牌与使用 API 的特定客户端相关联。但是 REST/OAUTH 纯粹主义者似乎不同意在身份验证中使用会话。他们声称 OAuth 是一个已经证明了自己的标准，这是我应该使用的，而不是提出我自己的晦涩方案。

4

1 回答 1

2

从您的描述来看，您似乎只处于两方场景中（开发人员编写代码代表他们自己访问您的 API，而不是代表最终用户），所以这确实意味着执行完整的 3-legged oAuth不需要场景。

您可以使用几乎任何身份验证方案，并且可以使用（API 密钥、其他 oAuth 授权类型 [见下文] 甚至 ID/Secret 组合。在 oAuth 世界中：

  • 查看其他 oAuth 2.0 授权类型：尤其是资源所有者 PW 授权 - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.3。它比 username-password 稍微好一点，因为 PW 并不是一直通过通道传递的（虽然它只传递一次），并且它假定编写代码的开发人员是凭据的所有者。

  • 看看 oAuth v1.0：这与 v2.0 有很多不同，但它确实具有一些人喜欢的一个特性是令牌的使用方式——而不是通过它们用于生成哈希的线路传递客户端，然后在服务器端验证哈希。它比检查密钥更昂贵和复杂，但更不容易受到攻击。

在非 oAuth 世界中，如果它主要是开发人员直接使用的服务器资源，那么 ID/Secret 或 API-Key 模式可能就绰绰有余，并且对您的开发人员来说更容易实现。

回复：oAuth - 如果您正在执行任何类型的用户身份验证，那么一定要坚持使用标准 - 这些东西很复杂，并且有库真的很有帮助。如果它是 developer-api，您可能不需要走那么远。

如果您希望 API 在理想世界中是安全的，那么任何需要安全令牌通过间隙的东西都应该使用 SSL 来保护，特别是如果该客户端代码可以在可能通过无线通信的移动设备或笔记本电脑上运行。如果不是这种情况，有人可以从其中一个开发人员那里复制一个令牌。

上面唯一避免这种情况的协议是 oAuth 1.0 变体，因为秘密永远不会离开客户端，而是用于散列。但这很复杂。最后一个要查看的是 Amazon AWS 模式，它进行类似于 oAuth 1.0 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html的散列，人们模仿了很多。

于 2012-05-27T12:41:06.433 回答