RESTful身份验证

Question

RESTful身份验证

RESTful身份验证意味着什么？它是如何工作的？我在Google上找不到一个很好的概览。我唯一的理解是，您在URL中传递会话密钥(备忘键)，但这可能是非常错误的。

Answer 1

这里的好人已经对这个话题说得够多了。但这是我的两分钱。有两种互动方式：人对机(Htm)机器对机器(Mtm)机器是公共分母，表示为REST API，参与者/客户端要么是人，要么是机器。现在，在真正的RESTful体系结构中，无状态的概念意味着所有相关的应用程序状态(即客户端状态)都必须与每个请求一起提供。相关的意思是，无论RESTAPI需要什么来处理请求并提供适当的响应。当我们在人机应用程序的上下文中考虑到这一点时，“基于浏览器的”(Browser-Based)，正如skrebel前面所指出的，这意味着在浏览器中运行的(Web)应用程序将需要将其状态和相关信息与它向后端RESTAPI发出的每个请求一起发送。考虑一下：您有一个数据/信息平台公开了RESTAPI资产。也许您有一个处理所有数据立方体的自助BI平台。但你希望你的(人类)客户通过(1)网络应用程序、(2)移动应用程序和(3)第三方应用程序访问这些应用程序。最终，即使是连锁的MTM也会导致HTM-右。因此，人类用户仍然处于信息链的顶端。在前两种情况下，您有一个人机交互的案例，即人类用户实际使用的信息。在最后一个例子中，您有一个机器程序使用RESTAPI。认证的概念是全面适用的。您将如何设计它，以便以统一、安全的方式访问RESTAPI？在我看来，有两种方法：路-1：首先没有登录。每个请求都执行登录。客户端发送标识参数+每个请求的特定请求参数。RESTAPI接受它们，掉头，点击用户存储(不管是什么)，并确认了auth。如果建立了auth，则为请求提供服务；否则，拒绝使用适当的HTTP状态代码对目录中所有RESTAPI的每个请求重复上述内容。路-2：客户端以一个auth请求开始。登录RESTAPI将处理所有此类请求。它接受auth参数(API键、uid/pwd或您选择的任何参数)，并根据用户存储(LDAP、AD或MySQLDB等)验证auth。如果被验证，则创建一个auth令牌并将其交回客户端/调用方。然后，调用方将这个auth令牌+请求特定的params和每个后续请求发送到其他业务RESTAPI，直到注销或租约到期为止。显然，在方法-2中，RESTAPI需要一种方法来识别和信任令牌是有效的。LoginAPI执行auth验证，因此目录中的其他RESTAPI需要信任“valetkey”。当然，这意味着需要在RESTAPI之间存储和共享auth密钥/令牌。这个共享的、受信任的令牌存储库可以是本地/联邦的，允许来自其他组织的RESTAPI相互信任。但我离题了。关键是，需要维护和共享“状态”(关于客户端的身份验证状态)，以便所有RESTAPI都能创建一个信任循环。如果我们不这样做，这就是方法-1，我们必须接受必须对任何/所有传入的请求执行身份验证的行为。执行身份验证是一个资源密集型的过程。想象一下，针对每个传入请求，针对用户存储执行SQL查询，以检查uid/pwd匹配。或者，加密和执行哈希匹配(AWS样式)。在架构上，我怀疑每个RESTAPI都需要使用一个通用的后端登录服务来执行这个任务。因为，如果你不这么做，你就到处乱扔代码。一堆烂摊子。所以更多的层，更多的延迟。现在，采取方式-1，并适用于HTM。你的(人类)用户真的关心你是否必须发送uid/pwd/散列或任何与每个请求相关的内容吗？不，只要你不打扰她，你每秒钟都会抛出这个/登录页面。如果你有顾客，祝你好运。所以，您要做的是将登录信息存储在客户端的某个地方，在浏览器中，就在开始时，并将其与每个请求一起发送。对于(人工)用户，她已经登录，并有一个“会话”可用。但在现实中，她每一次请求都要经过认证。路-2也是一样。你的(人类)用户永远不会注意到。所以没有造成伤害。如果我们向MTM申请1路呢？在这种情况下，由于它是一台机器，我们可以通过要求它提交每一个请求的身份验证信息来让这个家伙感到厌烦。没人注意你!在MTM上执行Way-2不会引起任何特殊的反应，这是一台该死的机器。它会不在乎的！所以，问题是什么适合你的需要。无国籍是要付出代价的。付出代价继续前进。如果你想成为一个纯粹主义者，那么也要为此付出代价，然后继续前进。最后，哲学并不重要。真正重要的是信息发现、展示和消费体验。如果人们喜欢你的API，你就做好了你的工作。