RESTful身份验证

RESTful身份验证是什么意思，它如何工作？我在Google上找不到很好的概述。我唯一的理解是您在URL中传递了会话密钥（记住），但这可能是非常错误的。

如何在RESTful客户端-服务器体系结构中处理身份验证是一个有争议的问题。

通常，它可以通过以下方式在HTTP上的SOA中实现：

• 通过HTTPS进行HTTP基本身份验证；
• Cookies和会话管理；
• HTTP标头中的令牌（例如OAuth 2.0 + JWT）；
• 使用其他签名参数的查询身份验证。

您必须调整甚至更好地混合使用这些技术，才能最好地匹配您的软件体系结构。

每个身份验证方案都有自己的PRO和CON，具体取决于安全策略和软件体系结构的目的。

通过HTTPS进行HTTP基本身份验证

大多数Web服务都使用基于标准HTTPS协议的第一个解决方案。

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

它易于实施，默认情况下在所有浏览器上都可用，但存在一些已知的缺点，例如浏览器上显示的可怕的身份验证窗口将持续存在（此处没有类似LogOut的功能），服务器端的额外CPU消耗，以及用户名和密码（通过HTTPS）传输到服务器的事实（在键盘输入期间让密码仅保留在客户端，并作为安全哈希存储在服务器上应该更为安全） 。

我们可能使用了摘要式身份验证，但它也需要HTTPS，因为它容易受到MiM或Replay攻击的侵扰，并且特定于HTTP。

通过Cookie的会话

老实说，在服务器上管理的会话并不是真正的无状态。

一种可能性是将所有数据保留在cookie内容内。而且，根据设计，cookie是在服务器端处理的（实际上，客户端甚至不尝试解释此cookie数据：它会在每次后续请求时将其交还给服务器）。但是此cookie数据是应用程序状态数据，因此客户端应在纯净的无状态环境中管理它，而不是服务器。

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

cookie技术本身是HTTP链接的，因此它不是真正的RESTful，应该是独立于协议的IMHO。它容易受到MiM或Replay攻击。

通过令牌（OAuth2）授予

一种替代方法是在HTTP标头中放置一个令牌，以便对请求进行身份验证。例如，这就是OAuth 2.0的功能。参见RFC 6749：

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

简而言之，这与cookie非常相似，并且会遇到相同的问题：不是无状态的，依赖于HTTP传输详细信息，并且存在很多安全漏洞（包括MiM和Replay），因此只能在HTTPS上使用。通常，将JWT用作令牌。

查询认证

查询身份验证包括通过URI上的一些其他参数对每个RESTful请求进行签名。请参阅此参考文章。

本文对此进行了定义：

所有REST查询都必须通过使用私有证书作为签名令牌对以小写字母顺序排序的查询参数进行签名来进行身份验证。URL编码查询字符串之前应先进行签名。

此技术可能与无状态架构更兼容，并且还可以通过轻量级会话管理（使用内存中会话而不是数据库持久性）来实现。

例如，这是来自上面链接的通用URI示例：

GET /object?apiKey=Qwerty2010

应该这样传送：

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

/object?apikey=Qwerty2010&timestamp=1261496500使用API​​密钥的私有组件，要签名的字符串是，签名是该字符串的SHA256哈希。

服务器端数据缓存始终可以使用。例如，在我们的框架中，我们在SQL级别而不是URI级别缓存响应。因此，添加此额外参数不会破坏缓存机制。

有关基于JSON和REST的客户端服务器ORM / SOA / MVC框架中的RESTful身份验证的一些详细信息，请参阅本文。由于我们不仅允许通过HTTP / 1.1进行通信，而且还允许通过命名管道或GDI消息（在本地）进行通信，因此我们尝试实现一种真正的RESTful身份验证模式，而不依赖于HTTP特定性（例如标头或cookie）。

以后的注释：在URI中添加签名可能被视为不正确的做法（例如，由于它将出现在http服务器日志中），因此必须加以缓解，例如通过适当的TTL来避免重播。但是，如果您的http日志受到威胁，则肯定会遇到更大的安全问题。

实际上，即将推出的OAuth 2.0 MAC令牌认证相对于当前的“令牌授予”方案而言可能是一个巨大的改进。但这仍在进行中，并且与HTTP传输相关。

结论

值得总结的是，REST实际上不仅基于HTTP，即使实际上它也大多是通过HTTP实现的。REST可以使用其他通信层。因此，无论Google回答什么，RESTful身份验证不仅是HTTP身份验证的同义词。它甚至根本不应使用HTTP机制，而应从通信层中抽象出来。而且，如果您使用HTTP通讯，那么借助“ 让我们加密”计划，您就没有理由不使用适当的HTTPS，这是除了任何身份验证方案之外所必需的。

我怀疑人们是否热烈地喊着“ HTTP身份验证”，是否曾经尝试过使用REST制作基于浏览器的应用程序（而不是机器对机器的Web服务）（无意冒犯-我只是认为他们从未遇到过麻烦） 。

我发现在用于生成可在浏览器中查看的HTML页面的RESTful服务上使用HTTP身份验证的问题是：

• 用户通常会收到一个由浏览器制作的难看的登录框，这对用户非常不友好。您不能添加密码检索，帮助框等。
• 注销或以其他名称登录是一个问题-浏览器将继续向站点发送身份验证信息，直到您关闭窗口
• 超时很困难

这里有一篇非常有见地的文章来解决这些问题，但这会导致很多特定于浏览器的javascript黑客，变通办法等。因此，它也不向前兼容，因此在发布新浏览器时将需要不断维护。我不认为设计简洁明了，再加上我觉得这是很多额外的工作和头痛的工作，因此我可以热情地向我的朋友们展示我的REST徽章。

我相信cookie是解决方案。但是等等，饼干是邪恶的，不是吗？不，不是，经常使用cookie的方式是邪恶的。Cookie本身只是一条客户端信息，就像浏览器在您浏览时会跟踪的HTTP身份验证信息一样。而且，每次客户端请求时，这些客户端信息都会发送到服务器，就像HTTP身份验证信息一样。从概念上讲，唯一的区别是服务器可以将这部分客户端状态的内容作为其响应的一部分来确定。

通过使会话成为具有以下规则的RESTful资源：

• 一个会话映射一个关键用户ID（也可能是最后行动时间戳超时）
• 如果存在会话，则表示该密钥有效。
• 登录意味着发布到/ sessions，将新密钥设置为cookie
• 注销意味着DELETEing / sessions / {key}（使用重载的POST，请记住，我们是浏览器，并且HTML 5还有很长的路要走）
• 通过在每次请求时将密钥作为cookie发送并检查会话是否存在和有效来完成身份验证

现在，与HTTP身份验证的唯一区别是，身份验证密钥是由服务器生成的，并发送给客户端，客户端不断将其发送回去，而不是由客户端根据输入的凭据来计算它。

converter42补充说，在使用https（我们应该这样做）时，重要的是，将cookie设置为安全标志，以便永远不要通过非安全连接发送身份验证信息。好点，我自己没看过。

我认为这是一个行之有效的解决方案，但我必须承认，我还不足以让安全专家来确定此方案中的潜在漏洞-我所知道的是，数百个非RESTful Web应用程序使用的本质上相同登录协议（PHP中的$ _SESSION，Java EE中的HttpSession等）。Cookie标头的内容仅用于寻址服务器端资源，就像可以使用接受语言来访问翻译资源等一样。我觉得是一样的，但也许其他人不是吗？你们觉得怎么样？

这里的好人已经对这个话题说了足够多的话。但是这是我的2美分。

有两种交互方式：

1. 人机（HTM）
2. 机器对机器（MTM）

机器是共同的分母，表示为REST API，而参与者/客户既是人类，又是机器。

现在，在真正的RESTful架构中，无状态的概念意味着必须为每个请求提供所有相关的应用程序状态（即客户端状态）。所谓相关，是指REST API处理请求和提供适当响应所需的任何内容。

当我们在人机应用程序的上下文中考虑此问题时（如Skrebbel所指出的那样，“基于浏览器”），这意味着在浏览器中运行的（网络）应用程序将需要随每个请求发送其状态和相关信息。它使用后端REST API。

请考虑以下事项：您拥有REST API的数据/信息平台公开资产。也许您有一个可以处理所有数据多维数据集的自助式BI平台。但是，您希望您的（人类）客户通过（1）Web应用程序，（2）移动应用程序和（3）一些第三方应用程序访问此文件。最后，即使是MTM链，也导致了HTM-对。因此，人类用户始终处于信息链的顶端。

在前两种情况下，您需要进行人机交互，而信息实际上是由人类用户使用的。在最后一种情况下，您有一个使用REST API的机器程序。

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

方式一：

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

方式2：

1. 客户端以身份验证请求开始
2. 登录REST API将处理所有此类请求
3. 它接受身份验证参数（API密钥，uid / pwd或您选择的任何内容），并根据用户存储（LDAP，AD或MySQL DB等）验证身份验证
4. 如果通过验证，则创建一个身份验证令牌，并将其交还给客户端/呼叫者
5. 然后，调用方将此身份验证令牌+请求特定的参数以及每个后续请求发送给其他业务REST API，直到注销或租约到期为止

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

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

但是我离题了。

关键是，需要维护和共享“状态”（关于客户端的身份验证状态），以便所有REST API都可以创建信任圈。如果我们不这样做，那就是方法1，我们必须接受必须对进入的任何/所有请求执行身份验证操作。

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

因此，更多的层，更多的延迟。

现在，采用Way-1并申请HTM。您的（人类）用户是否真的在乎您是否必须在每个请求中发送uid / pwd / hash或其他内容？不，只要您不每秒扔一次auth / login页面就可以打扰她。祝您有个好运。因此，您要做的就是将登录信息存储在客户端的某个位置，即一开始就在浏览器中，然后将其与每个请求一起发送。对于（人类）用户，她已经登录，并且可以使用“会话”。但实际上，她会根据每个请求进行身份验证。

与Way-2相同。您的（人类）用户将永远不会注意到。因此没有造成伤害。

如果将Way-1应用于MTM怎么办？在这种情况下，由于它是一台机器，我们可以通过要求该人员随每个请求提交身份验证信息来烦死他。没人在乎！在MTM上执行Way 2不会引起任何特殊反应；它是该死的机器。它可能不在乎！

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

最后，哲学并不重要。真正重要的是信息发现，表示和消费体验。如果人们喜欢您的API，那么您就干了。

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

1. 在身份验证服务器上创建一个公用/专用密钥对。
2. 将公钥分配给所有服务器。

3. 当客户端认证时：

   3.1。发出包含以下内容的令牌：

   • 到期时间
   • 用户名（可选）
   • 用户IP（可选）
   • 密码的哈希（可选）

   3.2。用私钥加密令牌。

   3.3。将加密的令牌发送回用户。

4. 当用户访问任何API时，他们还必须传递其auth令牌。

5. 服务器可以通过使用auth服务器的公钥解密令牌来验证令牌是否有效。

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

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

老实说，我在这里看到了不错的答案，但是令我感到困扰的是，有人将整个无状态概念推向了一个教条主义的极端。这让我想起那些只想拥抱纯OO的Smalltalk老粉丝，如果不是对象，那么您做错了。休息一下

RESTful方法应该使您的生活更轻松，并减少会话的开销和成本，请尝试遵循它，因为这样做是明智的选择，但是在您遵循某个学科（任何学科/指南）的那一刻，不再提供预期的收益，那么您做错了。当今一些最好的语言同时具有功能编程和面向对象的功能。

如果您要解决问题的最简单方法是将身份验证密钥存储在cookie中，然后将其发送到HTTP标头，则可以这样做，只是不要滥用它。请记住，当会话变得繁重时，它是不好的，如果您的所有会话都由包含密钥的短字符串组成，那有什么大不了的呢？

我乐于接受评论中的更正，但是（到目前为止）我只是不明白使我们的生活变得痛苦的原因，只是避免在服务器中保留大量的哈希字典。

首先，一个RESTful Web服务是无状态（或者换句话说，无会话）。因此，RESTful服务不存在也不应该包含会话或cookie的概念。在RESTful服务中进行身份验证或授权的方法是使用RFC 2616 HTTP规范中定义的HTTP授权标头。每个单个请求都应包含HTTP授权标头，并且该请求应通过HTTP（SSL）连接发送。这是在HTTP RESTful Web服务中进行身份验证和验证请求授权的正确方法。我已经在Cisco Systems的Cisco PRIME Performance Manager应用程序中实现了RESTful Web服务。作为该Web服务的一部分，我还实现了身份验证/授权。

当然，这与“会话密钥”无关，因为它通常用于指代在REST的所有约束内执行的无会话身份验证。每个请求都是自描述的，携带足够的信息以自行授权请求，而没有任何服务器端应用程序状态。

解决此问题的最简单方法是从RFC 2617中 HTTP的内置身份验证机制开始。

@skrebel（http://www.berenddeboer.net/rest/authentication.html）提到的“非常有见识的”文章讨论了一种复杂但确实很破损的身份验证方法。

您可以尝试访问该页面（应该仅对经过身份验证的用户可见）http://www.berenddeboer.net/rest/site/authenticated.html，而无需任何登录凭据。

（对不起，我无法对答案发表评论。）

我会说REST和身份验证根本不混在一起。REST表示无状态，但“已认证”是一种状态。您不能将它们放在同一层。如果您是RESTful的拥护者并且对状态不满意，则必须使用HTTPS（即将安全性问题留给另一层）。

我认为静态身份验证涉及在请求中传递身份验证令牌作为参数。例子是api对apikey的使用。我不认为使用cookie或http auth符合条件。

2019年2月16日更新

下面前面提到的方法实质上是OAuth2.0的 “资源所有者密码凭证”授予类型。这是启动和运行的简单方法。但是，使用这种方法，组织中的每个应用程序最终都会拥有自己的身份验证和授权机制。推荐的方法是“授权代码”授予类型。此外，在下面的较早答案中，我建议使用浏览器localStorage来存储身份验证令牌。但是，我已经相信cookie是用于此目的的正确选择。我在这个StackOverflow答案中详细说明了我的原因，授权码授予类型的实现方法，安全性注意事项等。

我认为以下方法可用于REST服务身份验证：

1. 创建一个登录RESTful API，以接受用于验证的用户名和密码。在传输过程中使用HTTP POST方法来防止缓存和SSL的安全性在成功进行身份验证时，API返回两个JWT-一个访问令牌（有效期较短，例如30分钟）和一个刷新令牌（有效期较长，例如24小时）
2. 客户端（基于Web的UI）将JWT存储在本地存储中，并且在随后的每个API调用中，都在“授权：承载＃访问令牌”标头中传递访问令牌
3. API通过验证签名和有效日期来检查令牌的有效性。如果令牌有效，请检查用户（它将JWT中的“ sub”声明声明为用户名）是否可以通过缓存查找访问API。如果用户有权访问API，请执行业务逻辑
4. 如果令牌已过期，则API返回HTTP响应代码400
5. 客户端在接收到400/401时，将使用“授权：承载＃刷新令牌”标头中的刷新令牌调用另一个REST API，以获取新的访问令牌。
6. 收到带有刷新令牌的呼叫后，通过检查签名和到期日期来检查刷新令牌是否有效。如果刷新令牌有效，请从数据库刷新用户的访问权限缓存，并返回新的访问令牌和刷新令牌。如果刷新令牌无效，则返回HTTP响应代码400
7. 如果返回了新的访问令牌和刷新令牌，请转到步骤2。如果返回了HTTP响应代码400，则客户端认为刷新令牌已过期，并要求用户输入用户名和密码。
8. 要注销，请清除本地存储

通过这种方法，我们正在执行昂贵的操作，每30分钟使用用户特定的访问权限详细信息加载缓存。因此，如果撤消访问权限或授予新的访问权限，则需要30分钟的时间进行反映或注销后再进行登录。

这样做的方法是：使用OAuth 2.0登录。

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

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

参见http://en.wikipedia.org/wiki/Public_key_infrastructure。如果您遵循正确的PKI标准，则可以识别出不正确使用被盗密钥的个人或代理商，并将其锁定。如果要求代理使用证书，则绑定会变得非常紧密。一个聪明而迅捷的小偷可以逃脱，但会留下更多的碎屑。

根据我的理解回答这个问题...

使用REST的身份验证系统，因此您无需实际跟踪或管理系统中的用户。这是通过使用HTTP方法POST，GET，PUT，DELETE完成的。我们采用这4种方法，并在数据库交互方面将它们视为CREATE，READ，UPDATE，DELETE（但是在网络上，我们使用POST和GET，因为这是锚标记当前所支持的）。因此，将POST和GET作为我们的CREATE / READ / UPDATE / DELETE（CRUD），然后我们可以在Web应用程序中设计路由，从而能够推断出CRUD所要实现的作用。

例如，在Ruby on Rails应用程序中，我们可以构建Web应用程序，这样，如果登录的用户访问http://store.com/account/logout，则该页面的GET可以视为尝试注销的用户。 。在我们的rails控制器中，我们将构建一个动作，将用户注销并发送回首页。

登录页面上的GET将产生一个表格。在登录页面上的POST将被视为登录尝试，并获取POST数据并将其用于登录。

对我来说，这是一种使用映射到其数据库含义的HTTP方法，然后考虑到这一点构建身份验证系统的实践，您无需传递任何会话ID或跟踪会话。

我仍在学习-如果您发现我说错的任何内容，请纠正我，如果您了解更多信息，请在此发布。谢谢。

对保护任何Web应用程序有效的提示

如果您想保护您的应用程序安全，那么绝对应该使用HTTPS而不是HTTP来开始，这样可以确保在您和用户之间创建安全通道，从而防止嗅探来回发送给用户的数据并有助于保留数据。交换了机密。

您可以使用JWT（JSON Web令牌）来保护RESTful API，与服务器端会话相比，这有很多好处，主要包括：

1-更具可扩展性，因为您的API服务器将不必为每个用户维护会话（当您有很多会话时，这可能是一个沉重的负担）

2- JWT是自包含的，并且具有定义用户角色的声明，例如，他可以在日期和有效期访问和发布的内容（此日期之后，JWT将无效）

3-更易于处理负载平衡器，并且如果您有多个API服务器，因为您不必共享会话数据，也无需配置服务器将会话路由到同一服务器，那么只要JWT的请求碰到任何服务器，就可以对其进行身份验证和授权

4-减轻数据库负担，不必为每个请求不断存储和检索会话ID和数据

5-如果您使用强键对JWT进行签名，则JWT不会被篡改，因此您可以信任随请求一起发送的JWT中的声明，而无需检查用户会话以及他是否被授权，您只需检查JWT，然后就可以知道该用户可以执行的操作。

许多库提供了使用大多数编程语言创建和验证JWT的简便方法，例如：在node.js中，最受欢迎的一种是jsonwebtoken

由于REST API通常旨在使服务器保持无状态，因此JWT与该概念更加兼容，因为每个请求都是使用自包含（JWT）的授权令牌发送的，而与服务器会话相比，服务器无需跟踪用户会话服务器是有状态的，以便记住用户及其角色，但是，会话也被广泛使用并具有其优点，您可以根据需要进行搜索。

需要注意的一件事是，您必须使用HTTPS安全地将JWT交付给客户端，并将其保存在安全的地方（例如，本地存储中）。

您可以从此链接了解有关JWT的更多信息