Reputation: 12925
I've spent the past week on SO and in books reading about authentication and started to roll out Basic Authentication for my WebAPI so that HTML clients can let users login/register/logout, but Basic Auth doesn't facilitate logging out so I'm back at square one.
Details:
I don't need to let users log in with other services. I don't need facebook or google logins. Just a username/password.
I need users to be able to log in / log out / register from the client application (not the browser).
I don't mind sending credentials over the wire since I'll be using SSL.
Currently there's only one client but there will be others accessing the API, so I'll need to implement something akin to api keys in the future. Maybe this is a separate issue.
I have a RESTish WebAPI that accepts/returns JSON to html/js clients in other domains.
This is for prototyping so I don't need the best possible solution, just something that's good enough for pre-release and has a low time-to-implement.
Where should I start? What would you do, and why? Is Forms Auth an option?
Upvotes: 3
Views: 2469
Reputation: 4387
Firstly and more importantly; SSL, SSL SSL It's a very simple step even major sites miss but its damned important (even with SSL's many current hard to exploit flaws).
You can use pretty much any sort of authentication with webapi; basic-auth; credentials; you could look at using OAUTH style authentication (note I say style as the spec is so loosely defined it offers pretty much EVERY option and multiple ways of achieving it).
First and foremost I'd look at WebApi as a choice; have you considered something else? such as http://www.servicestack.net/ which contains a whole range of authentication adapters https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization
Secondly it would be helpful to know what your authenticating and what its authenticating for (private data / uploads / access to some stuff); in order for an answer that contains 'just enough security'.
Forms authentication 'could' be used, and assuming your client is none-browser based you could achieve this by returning login via a service and responding with the formsauthentication token which you would need to keep in some sort of context for the period of use; assuming a timeout is set once the software has finished using the api the user would have to login again next time to reuse it.
As far as the web api / JS-Html frontend goes; to quote myself.
As its a JS app its probably worth taking a quick look at the owasp top 10 in relation to JS
A1 - Injection
A2 - Cross Site Scripting (XSS)
A3 - Broken Authentication and Session Management
A4 - Insecure Direct Object References
A5 - Cross Site Request Forgery (CSRF)
A6 - Security Misconfiguration
A7 - Insecure Cryptographic Storage
A8 - Failure to Restrict URL Access
A9 - Insufficient Transport Layer Protection
A10 - Unvalidated Redirects and Forwards
Theres a good post on creating a custom authorization filter for WebApi here http://www.west-wind.com/weblog/posts/2013/Apr/18/A-WebAPI-Basic-Authentication-Authorization-Filter (how-to/with code)
Upvotes: 0
Reputation: 19321
In the question you have
I don't mind sending credentials over the wire since I'll be using SSL.
In the comment to the answer you have said
I just don't want users sending plaintext passwords over the wire.
Not sure what exactly you are looking for but Forms Authentication is definitely an option. you can use basic authentication as well but it has a few drawbacks like you mentioned: no logout, etc. You must use HTTPS with basic authentication.
If browser popup is the main concern, you can get around that by preemptively sending the credentials in the very first request. Normally, the first request goes without the Authorization request header. Service responds with a 401 and sends back WWW-Authenticate response header indicating basic scheme. This is when browser pops up the dialog and asks for user id and password, packages it in the basic scheme and sends the Authorization header.
Upvotes: 2