![]() Later Note: adding a signature in the URI can be seen as bad practice (since for instance it will appear in the http server logs) so it has to be mitigated, e.g. Since we allow communication not only over HTTP/1.1, but also named pipes or GDI messages (locally), we tried to implement a truly RESTful authentication pattern, and not rely on HTTP specificity (like header or cookies). See this article for some details about RESTful authentication in our client-server ORM/SOA/MVC framework, based on JSON and REST. So adding this extra parameter doesn't break the cache mechanism. For instance, in our framework, we cache the responses at the SQL level, not at the URI level. Server-side data caching can be always available. The string being signed is /object?apikey=Qwerty2010×tamp=1261496500 and the signature is the SHA256 hash of that string using the private component of the API key. ![]() Should be transmitted as such: GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789 This technique is perhaps the more compatible with a Stateless architecture, and can also be implemented with a light session management (using in-memory sessions instead of DB persistence).įor instance, here is a generic URI sample from the link above: GET /object?apiKey=Qwerty2010 Signing should occur before URL encoding the Sorted in lower-case, alphabetical order using the private credentialĪs the signing token. See this reference article.Īll REST queries must be authenticated by signing the query parameters Query Authentication consists in signing each RESTful request via some additional parameters on the URI. In short, this is very similar to a cookie and suffers to the same issues: not stateless, relying on HTTP transmission details, and subject to a lot of security weaknesses - including MiM and Replay - so is to be used only over HTTPS. See the RFC 6749: GET /resource/1 HTTP/1.1 This is what OAuth 2.0 does, for instance. It is vulnerable to MiM or Replay attacks.Īn alternative is to put a token within the HTTP headers so that the request is authenticated. The cookie technique itself is HTTP-linked, so it's not truly RESTful, which should be protocol-independent, IMHO. Host: Cookie: theme=light sessionToken=abc123 But this cookie data is application state data, so the client should manage it, not the server, in a pure Stateless world. And, by design, the cookie is handled on the Server side (Client, in fact, does even not try to interpret this cookie data: it just hands it back to the server on each successive request). One possibility could be to maintain all data within the cookie content. To be honest, a session managed on the Server is not truly Stateless. ![]() We may use Digest Authentication, but it requires also HTTPS, since it is vulnerable to MiM or Replay attacks, and is specific to HTTP. ![]() It's easy to implement, available by default on all browsers, but has some known drawbacks, like the awful authentication window displayed on the Browser, which will persist (there is no LogOut-like feature here), some server-side additional CPU consumption, and the fact that the user-name and password are transmitted (over HTTPS) into the Server (it should be more secure to let the password stay only on the client side, during keyboard entry, and be stored as secure hash on the Server). Host: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ= This first solution, based on the standard HTTPS protocol, is used by most web services. You'll have to adapt, or even better mix those techniques, to match your software architecture at best.Įach authentication scheme has its own PROs and CONs, depending on the purpose of your security policy and software architecture. Query Authentication with additional signature parameters.How to handle authentication in a RESTful Client-Server architecture is a matter of debate.Ĭommonly, it can be achieved, in the SOA over HTTP world via:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |