后台：我正在尝试创建SMS API服务。开发人员具有Dev ID和分配给其开发者帐户的API密钥。开发人员将创建将向我的API发出调用的应用程序。但是必须首先验证发出呼叫的应用程序。
问题：我遇到的主要问题是身份验证。我读了OAuth并且几乎理解了它。我通读了this演示文稿（幻灯片71-82）。所有OAuth文章都谈论OAuth“舞蹈”或“三角恋”。我的问题似乎是，在我的情况下，我没有看到一个正确的三角形。或者，更好的方法是，三角形似乎并不完整。
我的意思是，就让我们说，LinkedIn，试图制作一些应用程序，帮助用户将他们的LinkedIn acc与twitter相关联，OAuth完全有道理。因为LinkedIn需要从用户身上获取来自Twitter的资源（因为用户有一个TWITTER帐户）。就我而言，只有消费者在我的服务中注册了开发者帐户。最终用户没有任何凭据供消费者代表询问。那么我该如何实现Oauth？那么消费者会询问提供商呢？它只会说“小心，我来了吗？”。 Cuz看起来毫无意义，除非它要求一个请求令牌以换取访问令牌。但在这种情况下，由于最终用户甚至没有帐户，这些步骤似乎毫无用处。
所以，我无法弄清楚如何解决这个身份验证问题。我曾尝试过使用php会话，因此它可以帮助我将令牌与使用API的特定客户端相关联。但REST / OAUTH纯粹主义者似乎对身份验证中会话的使用存在分歧。他们声称OAuth是一个已经证明了自己的标准，而这正是我应该使用的，而不是提出我自己的模糊方案。
答案 0 :(得分：2)
根据您的描述，您似乎只处于双方场景中（开发人员编写的代码代表自己访问您的API，而不是代表最终用户），这意味着确实完成了3不需要-legged oAuth场景。
您几乎可以使用任何身份验证方案，而且可以使用（API密钥，其他oAuth授权类型[见下文]甚至ID /秘密组合。在oAuth世界中：
查看其他oAuth 2.0 Grant类型：特别是资源所有者PW授权 - http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.3。它比用户名密码略好，因为PW不会一直传递到整个频道（虽然传递了一次），并且它假定编写代码的开发人员是凭证的所有者。
看看oAuth v1.0：这与v2.0有各种不同之处，但有一些人喜欢的功能就是使用令牌的方式 - 而不是通过电线传递它们用于在客户端生成散列，然后在服务器端验证散列。它比检查密钥更昂贵，更复杂，但不太容易受到攻击。
在非oAuth世界中，如果它主要是开发人员直接使用的服务器资源，则ID / Secret或API-Key模式可能绰绰有余，并且为开发人员实现起来要容易得多。
Re：oAuth - 如果您正在使用任何类型的用户身份验证，那么绝对坚持使用标准 - 这些东西很复杂，而且那里的库真有帮助。如果它是developer-api，你可能不需要那么远。
如果您希望API在理想的世界中是安全的，那么任何需要安全令牌通过间隙的内容都应该使用SSL保护，尤其是，如果该客户端代码可以在移动设备上运行可能通过无线通信的设备或笔记本电脑。如果不是这种情况，有人可以从其中一个开发人员那里获取一个令牌。
上述唯一一个避免这种情况的协议是oAuth 1.0变体，因为秘密永远不会离开客户端，而是用来代替哈希。但它很复杂。最后一个要看的是亚马逊AWS模式，它的散列类似于oAuth 1.0 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html，并且人们会模仿很多。