token认证 - RESTful认证




restful token (9)

RESTful认证是什么意思,它是如何工作的? 我无法在Google上找到很好的概述。 我唯一的理解是你在URL中传递会话密钥(remeberal),但这可能是非常错误的。


@skrebel( here )提到的'非常有见识'的文章讨论了一种令人费解的但真正破坏的身份验证方法。

您可以尝试访问该页面(该页面应该仅对经过验证的用户可见),无需任何登录凭证即可http://www.berenddeboer.net/rest/site/authenticated.html

(对不起,我不能评论答案。)

我会说REST和身份验证根本不混合。 REST意味着无状态,但“认证”是一种状态。 你不能让它们在同一层。 如果你是一个RESTful倡导者并且对状态不满,那么你必须使用HTTPS(即将安全问题留给另一层)。


I think restful authentication involves the passing of an authentication token as a parameter in the request. Examples are the use of apikeys by api's. I don't believe the use of cookies or http auth qualifies.


That's the way to do that: Using OAuth 2.0 for Login .

You may use other authentication methods other then Google's as long as it supports OAuth.


To answer this question from my understanding...

An authentication system that uses REST so that you do not need to actually track or manage the users in your system. This is done by using the HTTP methods POST, GET, PUT, DELETE. We take these 4 methods and think of them in terms of database interaction as CREATE, READ, UPDATE, DELETE (but on the web we use POST and GET because that is what anchor tags support currently). So treating POST and GET as our CREATE/READ/UPDATE/DELETE (CRUD) then we can design routes in our web application that will be able to deduce what action of CRUD we are achieving.

For example, in a Ruby on Rails application we can build our web app such that if a user who is logged in visits http://store.com/account/logout then the GET of that page can viewed as the user attempting to logout. In our rails controller we would build an action in that logs the user out and sends them back to the home page.

A GET on the login page would yield a form. a POST on the login page would be viewed as a login attempt and take the POST data and use it to login.

To me, it is a practice of using HTTP methods mapped to their database meaning and then building an authentication system with that in mind you do not need to pass around any session id's or track sessions.

I'm still learning -- if you find anything I have said to be wrong please correct me, and if you learn more post it back here. 谢谢。


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

通常,可以通过以下方式在SOA over HTTP世界中实现:

  • 基于HTTPS的HTTP基本认证;
  • Cookies和会话管理;
  • HTTP标头中的令牌(例如OAuth 2.0);
  • 使用附加签名参数查询身份验证

你必须适应甚至更好地混合这些技术,才能最好地与你的软件架构相匹配。

每个认证方案都有自己的PRO和CON,具体取决于您的安全策略和软件体系结构的用途。

基于HTTPS的HTTP基本认证

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

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

它很容易实现,默认情况下在所有浏览器上都可用,但有一些已知的缺点,比如浏览器上显示的糟糕的认证窗口,它会持续存在(这里没有LogOut-like功能),某些服务器端的附加CPU消费以及用户名和密码通过HTTPS传输到服务器这一事实(在键盘输入期间让密码仅保留在客户端,并在安全哈希上存储时应该更安全)服务器)。

我们可能使用摘要式身份验证 ,但它也需要HTTPS,因为它容易受到MiMReplay攻击,并且特定于HTTP。

通过Cookies进行会话

说实话,在服务器上管理的会话并非真正的无状态。

一种可能是维护cookie内容中的所有数据。 而且,通过设计,cookie在服务器端处理(客户端实际上甚至不会尝试解释这个cookie数据:它只是在每个连续的请求中将它传递回服务器)。 但是这个cookie数据是应用程序状态数据,因此客户端应该在纯粹的无状态世界中管理它,而不是服务器。

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

cookie技术本身是HTTP链接的,所以它不是真正的RESTful,它应该是协议无关的,恕我直言。 它容易受到MiMReplay攻击。

通过令牌授予(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使用。

查询认证

查询认证包括通过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)。

实际上, 对于OAuth 2.0即将推出的MAC令牌认证,在“授权令牌”当前计划方面可能是一个巨大的改进。 但这仍然是一项正在进行的工作,并且与HTTP传输有关。

结论

值得一提的是,REST不仅仅是基于HTTP的,即使在实践中它大部分都是通过HTTP实现的。 REST可以使用其他通信层。 因此,RESTful认证不仅仅是HTTP认证的同义词,无论Google如何回答。 它甚至不应该使用HTTP机制,而应该从通信层抽象出来。


已经有足够多的人在这里谈论这个话题了。 但这是我的2美分。

有两种交互模式:

  1. 人机对话(HTM)
  2. 机器对机器(MTM)

该机器是公共分母,表示为REST API,演员/客户机是人或机器。

现在,在一个真正的RESTful体系结构中,无状态的概念意味着必须为每个请求提供所有相关的应用程序状态(即客户端状态)。 通过相关,这意味着无论REST API需要如何处理请求并提供适当的响应。

当我们在人机交互的应用环境中考虑这个问题时,就像Skrebbel在上面指出的那样,“基于浏览器”意味着运行在浏览器中的(web)应用程序需要发送它的状态和相关信息制作到后端REST API。

考虑一下:你有一个公开的数据/信息平台作为一套REST API。 也许你有一个处理所有数据立方体的自助BI平台。 但是,您希望您的(人)客户通过(1)Web应用程序,(2)移动应用程序和(3)某个第三方应用程序访问此应用程序。 最后,甚至连锁MTMs导致HTM - 对。 因此,用户仍然处于信息链的顶端。

在前两种情况下,您有一个人机交互的例子,这些信息实际上是由用户使用的。 在最后一种情况下,您有一个使用REST API的机器程序。

认证的概念全面适用。 您将如何设计这个以便您的REST API以统一,安全的方式访问? 我看到这个的方式有两种方式:

方式1:

  1. 没有登录开始。 每个请求都会执行登录
  2. 客户端发送其标识参数+每个请求的请求特定参数
  3. REST API使用它们,转身,ping用户存储(不管是什么)并确认身份验证
  4. 如果auth已建立,则为请求提供服务; 否则,用适当的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将需要一种方法来识别和信任令牌为有效的。 Login API执行身份验证验证,因此您的目录中的其他REST API需要信任“代钥”。

这当然意味着认证密钥/令牌需要在REST API中进行存储和共享。 这个共享的可信任令牌存储库可以是本地/联合的,允许其他组织的REST API互相信任。

但我离题了。

关键是,需要维护和共享“状态”(关于客户端的身份验证状态),以便所有REST API都可以创建一个信任圈。 如果我们不这样做,那就是Way-1,我们必须接受必须对所有进入的请求执行认证行为。

执行认证是一个资源密集型过程。 想象一下,针对每个传入请求,执行SQL查询,针对您的用户存储检查uid / pwd匹配。 或者,加密并执行哈希匹配(AWS风格)。 在架构上,每个REST API都需要使用通用后端登录服务执行此操作。 因为,如果你不这样做,那么你在任何地方都会乱授权代码。 一团糟。

所以更多的图层,更多的延迟。

现在,采取Way-1并应用于HTM。 您的(人类)用户是否真的关心您是否需要每次发送uid / pwd / hash或其他内容? 不,只要你不打扰她每秒钟的认证/登录页面。 如果你有客户,祝你好运。 因此,您要做的是将登录信息存储在客户端,浏览器中的某个位置,然后将其发送到每个请求。 对于(人)用户,她已经登录,并且“会话”可用。 但事实上,她在每次请求时都经过身份验证。

和Way-2一样。 你的(人类)用户永远不会注意到。 所以没有伤害。

如果我们将Way-1应用于MTM会怎样? 在这种情况下,因为它是一台机器,所以我们可以通过要求它提交每个请求的认证信息来让这个人失望。 没人在乎! 在MTM上执行Way-2不会引起任何特殊反应; 它是一个该死的机器。 它可以小心!

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

最后,哲学并不重要。 真正重要的是信息发现,呈现和消费体验。 如果人们喜欢你的API,你做了你的工作。


说实话,我已经在这里看到了很好的答案,但是让我感到困扰的是,有人会将整个无状态概念带到极端教条的地步。 它让我想起了那些只想拥抱纯粹面向对象的旧式Smalltalk粉丝,如果某件事不是对象,那么你就错了。 给我休息一下。

RESTful方法应该让你的生活更轻松,减少会话的开销和成本,尽量遵循它,因为这是一个明智的做法,但是一旦你遵循一门学科(任何学科/指导方针)到极端的地方不再提供它打算的好处,那么你做错了。 今天一些最好的语言同时具有功能性编程和面向对象。

如果解决问题的最简单方法是将身份验证密钥存储在cookie中,并将其发送到HTTP头上,那么请执行此操作,不要滥用它。 请记住,当会话变得沉重而大时会话很糟糕,如果所有会话都包含一个包含密钥的短字符串,那么有什么大不了的?

我很乐意接受评论中的更正,但我只是没有看到让我们的生活变得悲惨的观点,以避免在我们的服务器中保留一个大的哈希字典。


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

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


首先,一个RESTful Web服务是STATELESS (或换句话说, SESSIONLESS )。 因此,一个RESTful服务没有,也不应该有涉及会话或cookie的概念。 在RESTful服务中执行身份验证或授权的方式是使用RFC 2616 HTTP规范中定义的HTTP授权标头。 每个请求都应包含HTTP授权标头,并且该请求应通过HTTP(SSL)连接发送。 这是进行身份验证并验证HTTP RESTful Web服务中的请求授权的正确方法。 我已为思科系统公司的思科PRIME Performance Manager应用实施了RESTful Web服务。 作为该Web服务的一部分,我也实施了认证/授权。

鲁本斯戈麦斯。





rest-security