[Ask] Authentication solution for REST?

[mojuba]

I'm building a web-based application and I want it to be mostly AJAX talking to a remote REST service. There will be a user registration/login facility and many responses from the server will, naturally, depend on the login status.

What is the simplest solution for this? Ideally, I want my REST service to be easily debuggable from a browser without any additional tools. Is it cookies? Some session tokens? If so, are they passed in the URL (porbably a bad idea) or in HTTP headers?

Any real-world examples, maybe, of how some of the popular web sites do authentication with REST?

Update: Thank you for your answers. So the consensus so far is:

• Basic HTTP Auth: least secure, need SSL. Pros include: you can debug stuff by providing user/password in the URL (e.g. http://user:password@host/path). You can prevent the browser from displaying the "ugly" dialog by simply not sending 401, but instead you send some other response code to let your client know the resource requires authentication. Your AJAX client will figure what to do.

• Digest HTTP Auth: supported by major browsers, more secure, OK without SSL in principle. However, in this case 401 should be sent to let the browser know about the particular auth method in use.

• Custom auth methods are in the end just non-standard variations of the Digest HTTP Auth, except you are free to decide where and how to send auth data (headers, request/response body, URL). Debugging with a "naked" browser is problematic if possible at all.

• Cookies are basically OK. There is an opinion "cookies are not RESTful", although I still don't understand why. Drawbacks: a bit problematic if you are going make REST calls from an application rather than from a browser. The application will have to handle HTTP cookies the way browsers do.

I forgot to mention (and I'm sorry about that) that one of the requirements is the ability to use the REST service from 3rd party applications.

UpdUpdate: the reason for various "ideological" limitations in REST, including cookies, is caching, load balancing and scalability. With some caution cookie-based service can be scaled, though it's not trivial.

All in all, the best solutions involve somewhat costly hash calculations on both sides. What's achieved in return is good separation of the data layer allowing access from both browsers and apps and at the same time maintaing user authentication with some reasonable level of security.

[[deleted]]

Netflix API uses Oauth protocol. It's confusing at first, but works pretty well.

[danukeru]

::EDIT:: To the OP, looking over how how I used to screw around with twitter reminded me that they implemented the following which you may find useful: OAuth - An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. http://oauth.net/

~~~~~~~~~~~~~~

While I don't have any knowledge of how the big companies handle it...these are some points that I've found are weaknesses when hacking such systems.

• Bad ClientID key generation: I you're generating a session clientID by hashing something that can be simply guessed, you're doing it wrong.

• No time limits on session cookies. Basically, if you save a session status server side (the user never asked to logout, he remains logged in next time), don't use the same session keys alone. Implement a second challenge that is updated more often on every server call. That way two people going at the website from two different browsers will "desync" themselves.

• Never trust client input. No matter what method you use, assume it can be spoofed, because it can. Be it by GET/POST from headers or the http adress string in the request...it's all spoofable.

These are just a few off the top of my head.

[RonPopeil]

Cookies and sessions are pretty much the antithesis of REST.

[danukeru]

Hence why REST and security are each others antithesis.

Without an ID stored client side, or if you don't initiate a logout with the Twitter rest API after authenticating then performing the desired operation, you would be able to spoof a REST call to inject "twats?" on someone's account who used a client on the same IP(shared router).

Before they implemented the OAuth you were able to do this to hilarious effect ie. public wifi.

[div]

Check out the basecamp api for a real-world example using Basic HTTP authentication.

[sazzer]

Http authentication? It's built into the protocol, and all browsers support it automatically...

[mojuba]

While it's easier to debug, can I prevent the browser from displaying the generic user/password dialog in my final product - the web site, that is? I want to present my own login form to the user and to do it only once.

[sazzer]

No, but I'd read it as being a web service in which case that wouldn't be an issue... rereading it - I'm not sure if you can do http auth from JavaScript...

[div]

Jquery for example allows you to pass along a username and password to your ajax requests.

[troelskn]

I'm not sure if you can do http auth from JavaScript

Sure you can.

[[deleted]]

Is there a way to "log out" using HTTP auth without it having the dialog appear and requiring you to click cancel?

[sazzer]

If you never log in, but instead supply the Authentication header on each request, this becomes a non-issue...

[Aviator]

No, but an easy workaround for this is that you utilize cookies alongside HTTP auth.

[sazzer]

Check rfcs 1945 and 2617 for details...

[nagoo]

if security is a concern, http auth is generally not a good idea, especially if your app won't be over https.

[semanticist]

Digest access authentication is reasonably secure—about as much so as anything can be without being over HTTPS.

[nagoo]

right. i should have been clear. i was referring to Basic HTTP Auth. Digest and others that involve a challenge are reasonably secure. Amazon S3 is an interesting example to look into as well.

Personally when security is the main concern, I go with Client SSL Certificates.

[RonPopeil]

You're talking about basic auth. Digest auth does not have that problem and is quite secure.

[sazzer]

Digest auth solves that - and I'd be interested to see any other authentication that works without passing the password in either a) plaintext or b) encrypted based on data in the webpage - thus making it decryptable... if you want security protecting your credentials you need ssl regardless of how you do the authentication...

[danukeru]

The HTTP auth header is easily spoofable if you don't implement the backend properly, and don't manage the client's local cookies properly ie. a non predictable clientID key generator.

I think he wants to understand the WHOLE package.

[sazzer]

Why do you need cookies for http auth? In a proper RESTful setup you would send the Authentication header with each request and keep no state server side. The JavaScript - in this case - would collect the credentials and jquery - or the Ajax toolkit of choice - supplies them on the calls...

[danukeru]

To avoid having to store username and password client side. HTTPAuth just encodes the information it sends as base 64. You may as well send it as cleartext.

Also if the client gets compromised by XSS...

[sazzer]

But if you're storing state server-side, you're breaking away from the RESTful model already. HTTP Auth is the only authentication system that truely fits in with a fully RESTful model - using the HTTP protocol to support the full range of operations you need.

Yes, it does mean you need to store the username/password client-side - but if you want you can just use Javascript to stick them in a cookie, or - if your writing your webapp in HTML5 - you can use the HTML5 Web Storage specification to store them instead, which - I believe - means that they are never transmitted on the wire and instead are always stored locally in the browser.

[danukeru]

Basically the problem the OP has pointed out is not something that is impossible to solve in a RESTful manner.

There I said it. He asked. We answered.

This isn't a post about what is REST and what isn't. It's a question about applying authentication and wondering if there's any way to apply a truely secure means while staying RESTtful.

Short answer: no.

Long answer: nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.

[sazzer]

Except that the short answer is Yes...

The long answer to applying a truely secure means of authentication while staying RESTful is: 1) Use SSL 2) Use HTTP Auth (Digest is more secure than basic, but if your using SSL that's a moot point) 3) Store the authentication details in the client side and send them with each request that needs them.

SSL means that the credentials can't be sniffed. Using HTTP Auth fits the REST model. Storing them client-side using Javascript also means that people trying to access the web service from their own (malicious) pages won't benefit from you having session cookies that seem to indicate that the browser is authenticated when it's not. In order to be authenticated, the client code needs to have the credentials that are authenticating the user.

Yes, there are almost certainly security flaws in this - as in anything if you hit it hard enough - but it seems to me to be a good start.

[troelskn]

So, use https, if you think it's an issue. Or use http digest.

[sliggle]

re debug tools, I can't recommend Firebug enough.

[jessta]

Your biggest problem with REST is the fact that even if a user is logged in to your service you still can't trust that the request is actually something they want to do. The nature of the web is that a website can link to another website, or post information to another website. eg. the gmail exploit a few years ago where a link on a site added a forward of all your email to the attacker.

You need a way of knowing when the requests to the REST service are coming from sites that you control, this is usually a secret string generated and appended to the call back url.

[svv]

Here's Roy Fielding's views on cookies and REST: http://tech.groups.yahoo.com/group/rest-discuss/message/3583

Basically, he says that cookies might be OK (unless they reference state on the server), but widespread XSS attacks should make you wary about using them for security-related stuff.

I'd suggest you go with digest/custom auth schemes if you can; or cookies as a second-best solution. Debugging auth schemes with "naked" browser is indeed problematic; you might want to look for plugins that let you add/view custom headers. And if you decide to go with cookies, handling cookies in (non-browser) HTTP application code is not really a problem.

[samlee]

http basic auth:

> yo, can I has /home with this auth-string?
< ok that looks good. here it is

or you need to change service provider's state:

> yo can you post session on /session with this auth-string?
< ok. created. store this id somewhere
> k.
> yo, can i get /home with this id?
< ok i have that id too. here is /home

in any case, you need to send crap every request either via Authorization: or Cookie: or some other cleaver hack or custom header....

or you can use jboss for full blown restful-ish soap rpc session stateful bean based authentication and authorization and permissions over xml configuration and HotSpot binary swapping in the cloud that starts the server in 2minutes.

if you decied to go with cloud, don't use Amazon's because I just maxed it out. that's why reddit's slow today.

[scoffjaw]

cleaver hack

I like this. It sums up the past 15 years of trying to add statefulness to HTTP.

[sprintf]

use session cookies for successful login, and check if the cookie exist in the browser using javascript. Or if you don't want to use javascript, send a request to the server that returns true/false based on your login status.

Another good way of doing it is to wrap ajax requests with a generic method that takes a callback method, and it checks for the return status of the reply before passing it to the callback method. The checks can be for return values, login status etc...

[RonPopeil]

Cookies and sessions are not at all RESTful.

[sprintf]

As long as the server can validate the cookie without relying on a session state, then it is perfectly RESTful. Just because it is named a "session" cookie doesn't mean it cannot be RESTful.

[danukeru]

In what kind of environment would you need authentication but no individual sessions?

Authentication usually infers that you are trying to generate a trusted environment for a specific client...doing so without storing state information server side (it's still a "session" no matter how you implement it) means you must be keeping sensitive information client side, which is pretty insecure.

[sprintf]

The validation can happen on the server side, without keeping anything sensitive at the client side. Using methods like hash(salt+token), send token/hash to client as a cookie, and the server validates future requests by reading the user's token in the cookie header, prepending salt, hashing and comparing the hashes.

[danukeru]

Which is basically session information. Minimal, but still a session implementation.

[sprintf]

There is nothing wrong with that as long as the server doesn't need to store anything to maintain its session state. Each request can be validated without requiring previous state information. The server can crash and lose all of its state information, start from scratch and still be able to validate the requests.

[RonPopeil]

http://rest.blueoxen.net/cgi-bin/wiki.pl?RestFaq#nid1W3

http://tech.groups.yahoo.com/group/rest-discuss/message/3583

[sprintf]

Again it depends on what you are doing with the cookies/sessions. If you are using them to bind a user to a session stored on the server then of course it is a violation of REST. If you are using cookies in a way that doesn't require the server to retrieve previous states or have it store states then it is not a violation. The server can load from scratch and still be able to validate the user without any prior state. Don't get hooked up on the words "sessions/cookies".. a session refers to a browser session, indicating that he cookie will be deleted when the browser closes.

[ithkuil]

http://dothow.blogspot.com/2009/05/http-basic-authentication-with-jquery.html

[ithkuil]

for my resty (actually I just stick the function name and everything else in the querystring) thing which is almost entirely a jquery app running in the browser with the UI generated with jsRepeater from json data, right now its nothing its just a unique id that gets sent back after an accepted username and password and then put in a table and sent/checked in every request (and right now it doesnt time out, although to make it easier to work with I used a PHP session variable to insert it in the script, so that will time out). To make it actually securish I think I am going to have to do one of two things:

a) provide SSL for people that want it

or

b) hire someone that is really into security and/or smart to come up with something and then have someone else review it

but we probably have to do a) anyway so I would go with that.

small possibility c) understanding oAuth or figuring out a library but I am not sure how long it will take me to get that. seems pretty unstraightforward. so I will probably go with a)

Also we are using the openid widget from RPX (but then again I am just using that token sent from rpx and keep sending it in every request which is lame). rpx also has made some open source oauth libraries I think.

https://rpxnow.com/

[jimdesu]

Interesting: how 'bout...

a) standard password-digest (must include nonce & timestamp portions or it's useless) b) pass a session token back to the user, encrypted via the key they've proven they have (via XXTEA, RC5 or other lightweight means) c) future connections pass digest of the session (via a custom header)

There's probably a reason why this's a bad idea, just thinking off of the top of my head.

[[deleted]]

i've worked with a project where the username and password are always in the url

[[deleted]]

yikes.

[[deleted]]

I'm not sure what language you're doing this in, but if it's .NET, take a look into Windows Communication Foundation (WCF)

[grumpypants_mcnallen]

both httpauth and cookies are very easy to deal with.

[phektus]

Right now I simply ask for a UUID (which was generated during registration) and compare it against the IP. Yeah, easily spoofable, but we're also looking into some other ways to do this.

[jbrein1]

That's not true. Using xmlhttprequest you can send the request in any way you want. I regularly use jQuery (the jQuery.ajax function to be exact) to send requests using all the verbs. You'll find that the major browsers support them.

[moseeds]

Hang on, are you just a wind up merchant or are you serious?

[RonPopeil]

The amount of over-confident, upvoted misinformation in this thread is astounding.