非浏览器使用者的Restful验证 [英] Restful authentication for non browser consumers

问题描述

我有一个作为ASP MVC应用程序编写的Web服务，它基本上使用滚动Cookie作为其身份验证机制。因此，有人通过https向服务发送用户名和密码，然后验证它们，并向其发送包含令牌，用户标识符和时间戳为HTTPONLY和SECURE的cookie。然后，每当用户需要访问需要认证的页面时，cookie被发送并通过针对用户的时间戳和令牌进行验证，假设通过它，然后发出新的时间戳并将其发送回用户。

此方法工作到今天，虽然仍然有可能的CSRF（减少滚动时间戳）和一些其他漏洞，这是一个风险，当前的项目团队愿意生活，有一个大的技术债务卡来寻找更好的方法，但这是另一个讨论，因为我们的主要目标是无状态服务，所以它可以轻松扩展。

一方面，现在的问题是，我们被要求向服务中的其他第三方披露数据。然而，他们不会像使用浏览器的普通用户那样消费这些数据，而是作为某种平台上的某种应用程序。所以现在我想知道是否有一些更好的方式为基于应用程序的消费者认证自己，因为目前他们需要发送一个http请求进行身份验证，然后获取返回的cookie，并为限制请求发送它。然而，其他第三方然后需要保持杂耍这个cookie每当他们想从我们的系统，这似乎有点痛苦的数据。

那么，还有另一种方式，我看不到这一点吗？因为我可以看到保持它无状态的两种方法是每次在querystring上发送一些令牌，这再次需要他们进行身份验证和存储，并使查询字符串不那么干净。

解决方案

如果你真的关心保持您的API RESTful，在querystring上发送凭据肯定是一个没有，因为在REST中，整个URI是资源的不透明标识符，并且使用cookie是服务和HTTP之间不必要的耦合。正确的认证方式将是协议允许和标准化的任何内容，因此，在您的情况下，通过WWW认证和授权头。客户端应该在每个请求的Authorization：Basic头中发送他们的用户名和密码（当然总是使用SSL）。

如果你真的想使用令牌客户端通过用户名：password验证，您也可以接受它作为自定义授权方案，在同一标题中。例如，像：

 授权：MyCompany apitoken =12k9023nd02890382n8902
  / pre> 
 
 
每当你怀疑什么是RESTful方式做某事时，只要考虑你使用的协议的标准。这是REST背后的限制之一。每当你要记录一些代替标准化功能的东西，你就错了。如果标准不足以满足您的需求，可以添加一些东西，比如自定义auth方案和这里的令牌。
 
I have a web service written as an ASP MVC application which basically uses rolling cookies as its authentication mechanism. So someone sends their username and password over https to the service, it then verifies them and issues them a cookie containing a token, user identifier and timestamp as HTTPONLY and SECURE. Then whenever the users need to access pages which require authentication the cookie is sent over and verified with the timestamp and the token against the user, assuming that passes it then issues a new timestamp and sends it back down to the user.

This method works to date and although there are still possibilities of CSRF (reduced by the rolling timestamp) and a few other vulnerabilities it is a risk that the current project team are willing to live with, there is a big technical debt card to look into better ways, but thats for another discussion, as our main goal was a stateless service so it could scale easily.

Anyway that all to one side, the issue now is that we have been asked to expose data to other 3rd parties from the service. They however wont be consuming this data like a normal user with a browser, but as an application of some kind on any sort of platform. So now I am wondering if there is some better way for application based consumers authenticate themselves, as currently they would need to send a http request to authenticate, then take the returned cookie, and send it over for restricted requests. However the other 3rd parties then need to keep juggling this cookie whenever they want to get data from our system, which seems a bit of a pain for them. 

So is there another way I cannot see to accomplish this? as the 2 ways I can see to keep it stateless are to send some token over on the querystring each time, which again would require them to authenticate and store it, and would make the querystring a bit less clean. Then the other way is as we currently do it using cookies as the state mechanism.
解决方案
If you're genuinely concerned with keeping your API RESTful, sending credentials on the querystring is definitely a no-no, since in REST the whole URI is an opaque identifier for a resource, and using cookies is an unnecessary coupling between the service and HTTP. The correct way to authenticate would be whatever is allowed and standardized by the protocol, so, in your case, through the WWW-Authenticate and Authorization headers. The clients should send their username and password in an Authorization: Basic header on every request (always use SSL, of course).

If you really want to use a token after the client is authenticated with username:password, you can also accept it as a custom authorization scheme, in the same header. For instance, something like: 
Authorization: MyCompany apitoken="12k9023nd02890382n8902"
Whenever you're in doubt about what's the RESTful way to do something, just think what's the standard for the protocol you're using. That's one of the constraints behind REST. Whenever you have to document something that is replacing an standardized functionality, you're doing it wrong. If the standard isn't enough for your needs, it's fine to add something, like the custom auth scheme with the token here.

                        
这篇关于非浏览器使用者的Restful验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！