当主应用程序基于OAuth API时，如何对其进行身份验证

我开始了一个新的网络项目，我打算使它基于API；也就是说，我想首先构建API，通过OAuth进行身份验证，然后构建一个网站，可能还有使用API处理数据的移动应用程序。我还着眼于向公众开放API

这是我的问题；我正在努力弄清楚如何认证这些“官方”应用程序，包括我自己制作的主站点

在OAuth中，客户机为每个用户创建一个帐户，然后通过在主站点登录的资源所有者来寻求访问权限。这显然对我不起作用，因为主站点和客户端是同一个地方，这也意味着我的用户应该创建两个帐户来使用我的网站

我相信twitter使用自己的API来运行twitter.com，我得到的印象是，这种方法正在变得非常正常，因此必须有一种标准的方法

我一定错过了什么，但是什么

托管两个版本的“API”。一个映射到外部域

api.yoursite.com

，并启用OAuth来验证所有请求。另一个内部版本只能在您的服务器池、您的官方应用中访问。因为只有你的官方应用程序可以“强”访问它的第一个地方< /强>，请考虑所有对内部API信任的请求。 如果希望同一应用程序同时管理外部和内部调用，可以选择

根据传入的IP地址区分外部和内部请求

实现API以接受用于身份验证的“VIP通行证”或OAuth令牌之一。外部应用程序使用OAuth令牌代表某些用户执行操作。官方应用程序使用“VIP通行证”代表任何用户执行操作

您将API（业务逻辑）与用户身份验证（例如登录）和第三方应用程序授权（OAuth）混淆

twitter.com使用自己的API是正确的。但是他们不在自己的站点上使用OAuth。当你在twitter.com上时，他们的API可以通过cookie身份验证为自己提供。简单地说：你已经登录了

一旦你离开twitter.com，你就必须使用OAuth。现在，应用程序正在代表用户使用API

总而言之。您不需要为“自己的”web客户端专门使用OAuth来使用自己的API。您需要OAuth或其他授权机制来发布您的API，它也可以方便地用于您自己的“官方”应用程序

---

真的没有必要区分你自己的官方应用和第三方应用。不管怎么说，从技术的角度来看，都不是这样

很好，这很有道理。现在看起来很明显，但我需要把它说清楚。但似乎没有理由主办两个不同的版本，而是有两种方式来验证，就像在公认的答案中一样。