I'm playing around with writing a stateless, REST based API that I plan to consume from a couple of different places, one of which will be a single-page Javascript webapp. The idea is basically to have a single API that is used from the various different clients - including ones that are potentially written by other people, but still potentially need access to user data - instead of having different APIs for different clients.
The problem I'm currently hitting up against is Authentication. Ideally I'd like to use something standard here instead of rolling my own, but I'm struggling to find something standard that actually fits. I'm also trying to avoid the solution of different authentication mechanisms depending on who is making the call. At this stage I don't actually need anything more than just authentication of the user that is actually using the application - via username and password, or similar - but if/when clients that aren't the web page want to use it they should probably be authenticated as well.
From what I've been looking at, it seems that the best way to do this is actually to just use HTTP Basic authentication over an HTTPS connection. I can't help but think that this is missing something though. The obvious alternatives seem to be OAuth 1.0 - which requires that the potentially insecure Javascript session knows the Client Secret - or OAuth 2.0 - which seems to go back to using the username/password over SSL to generate an access token, and then using that access token on future requests again over SSL, which is basically the same as HTTP Basic but obfuscated a bit.
Note that I've not counted HTTP Digest here, simply because - as I understand it - what's passed to the server is something that includes the password in a non-retrievable form (i.e. hashed), and if I store the password in the backend in a non-retrievable form as well then I can't compare the two...
