这就是实现这一点的方法：使用OAuth 2.0进行登录。

您可以使用Google以外的其他身份验证方法，只要它支持OAuth。

我认为restful身份验证涉及将身份验证令牌作为请求中的参数传递。示例是api对apikey的使用。我认为使用cookie或http身份验证不合格。

这就是实现这一点的方法：使用OAuth 2.0进行登录。

您可以使用Google以外的其他身份验证方法，只要它支持OAuth。

这里是一个真正且完全的RESTful身份验证解决方案：

在身份验证服务器上创建公钥/私钥对。将公钥分发给所有服务器。当客户端进行身份验证时：3.1.发行包含以下内容的代币：到期时间用户名（可选）用户IP（可选）密码散列（可选）3.2.使用私钥加密令牌。3.3.将加密令牌发送回用户。当用户访问任何API时，还必须传递其身份验证令牌。服务器可以通过使用身份验证服务器的公钥解密令牌来验证令牌是否有效。

这是无状态/RESTful身份验证。

注意，如果包含密码哈希，则用户还将发送未加密的密码以及身份验证令牌。服务器可以通过比较散列来验证密码是否与用于创建身份验证令牌的密码匹配。需要使用HTTPS之类的安全连接。客户端的Javascript可以处理获取用户的密码并将其存储在客户端，可以存储在内存中，也可以存储在cookie中，可能使用服务器的公钥进行加密。

关于这个话题，这里的好心人已经说得够多了。但这是我的2美分。

有两种交互模式：

人对机器（HTM）机器对机器（MTM）

机器是共同的分母，表示为RESTAPI，参与者/客户端要么是人，要么是机器。

现在，在真正的RESTful架构中，无状态的概念意味着所有相关的应用程序状态（意味着客户端状态）都必须随每个请求一起提供。通过相关，这意味着RESTAPI处理请求和提供适当响应所需的一切。

当我们在人对机器应用程序的上下文中考虑这一点时，正如Skrebel在上面指出的那样，“基于浏览器”，这意味着在浏览器中运行的（web）应用程序将需要将其状态和相关信息及其向后端REST API发出的每个请求一起发送。

考虑一下：您有一个数据/信息平台公开的RESTAPI资产。也许您有一个自助BI平台来处理所有数据立方体。但您希望您的（人类）客户通过（1）web应用程序、（2）移动应用程序和（3）某些第三方应用程序访问此应用程序。最后，即使是MTM链也会导致HTM-right。因此，人类用户仍然处于信息链的顶端。

在前两个案例中，您有一个人机交互的案例，信息实际上是由人类用户使用的。在最后一种情况下，您有一个使用RESTAPI的机器程序。

身份验证的概念适用于所有领域。您将如何设计它，以便以统一、安全的方式访问REST API？在我看来，有两种方式：

途径1：

首先，没有登录。每个请求都执行登录客户端发送其标识参数+特定请求每个请求的参数REST API接收它们，转身，ping用户存储（无论是什么）并确认授权如果建立了身份验证，则为请求提供服务；否则，拒绝具有适当的HTTP状态代码对所有REST API中的每个请求重复上述步骤目录

路线-2：

客户端以身份验证请求开始登录REST API将处理所有此类请求它接受auth参数（API密钥、uid/pwd或任何您select），并根据用户存储（LDAP、AD或MySQL DB等）验证身份验证如果已验证，则创建一个身份验证令牌并将其交还给客户/呼叫方然后，调用者将此身份验证令牌+请求特定参数与对其他业务REST API的每个后续请求，直到注销或租约到期

显然，在Way-2中，RESTAPI需要一种方法来识别和信任令牌的有效性。Login API执行了身份验证，因此，目录中的其他REST API需要信任“代客密钥”。

当然，这意味着需要在RESTAPI之间存储和共享身份验证密钥/令牌。这个共享的、可信的令牌存储库可以是本地/联合的，允许其他组织的REST API相互信任。

但我跑题了。

关键是，需要维护和共享一个“状态”（关于客户端的身份验证状态），以便所有RESTAPI都能创建一个信任圈。如果我们不这样做，即Way-1，我们必须接受必须对任何/所有传入的请求执行身份验证。

执行身份验证是一个资源密集型过程。想象一下，针对每个传入的请求，对用户存储执行SQL查询，以检查uid/pwd匹配。或者，加密并执行哈希匹配（AWS风格）。在架构上，我怀疑每个RESTAPI都需要使用一个通用的后端登录服务来执行此操作。因为，如果你不这样做，那么你就会到处乱扔授权码。一团糟。

所以层数越多，延迟就越大。

现在，选择Way-1并向HTM申请。您的（人类）用户真的关心您是否必须在每个请求中发送uid/pwd/hash或其他内容吗？不，只要你不打扰她，每秒都会抛出auth/login页面。如果你这样做的话，祝你有客户。所以，你要做的是将登录信息存储在客户端的某个位置，在浏览器中，一开始就存储，并随每个请求一起发送。对于（人类）用户，她已经登录，并且“会话”可用。但事实上，她的每一个请求都经过了认证。

与路线2相同。你的（人类）用户永远不会注意到。所以没有造成伤害。

如果我们将Way-1应用于MTM怎么办？在这种情况下，由于它是一台机器，我们可以要求它在每次请求时都提交身份验证信息，从而让这个家伙见鬼去。没人在乎！在MTM上执行Way-2不会引起任何特殊反应；这是一台该死的机器。它可以不在乎！

所以，问题是什么适合你的需要。无国籍需要付出代价。付出代价，继续前进。如果你想成为一个纯粹主义者，那么也要为此付出代价，然后继续前进。

最终，哲学无关紧要。真正重要的是信息发现、展示和消费体验。如果人们喜欢你的API，你就做好了自己的工作。

使用公钥基础结构（其中密钥的注册涉及适当的绑定）可确保公钥以确保不可抵赖的方式绑定到分配给其的个人

看见http://en.wikipedia.org/wiki/Public_key_infrastructure . 如果您遵循正确的PKI标准，可以识别并锁定不正确使用被盗密钥的人或代理。如果要求代理使用证书，则绑定变得非常紧密。一个聪明且行动迅速的小偷可以逃跑，但他们会留下更多的面包屑。