I own a web application (single page application with Angular), that asks for some data through a set of REST APIs based on my server-side application (using Play Framework 2.2.1).
So basically, I'm not an expert in security and so I initially wanted to use a "tool" for implementing authentication easily. Thus I chose to make use of SecureSocial.
I customize it to fit my needs, but after reading some documentation about REST authentication scheme, I realized that I'm likely to be in a wrong way.
Why? Simply because it's based on a Session-token mechanism rather than a full stateless solution.
In short, the authentication workflow is:
- The user logs in the web application through a traditional form (e-mail/password)
- Server checks for the validity of the credentials (comparing BCrypt hashes for the password), and if valid, returns a cookie containing a kind of authentication token. This authentication token is also stored in server cache (Play configured to access a Memcached store), in order to be able to make some comparisons each time the user asks for a restricted (in term of visibility) functionality.
Pros of this solution:
..this works well for controlling access to RESTRICTED API.
- This solution requires a datastore to store the authentication token on servers, in order to compare which the ones provide by client at each request attempt. Currently, I make use of Memcached.
- Unable to restrict access to some small list of clients. Indeed, what if I want to restrict all REST API accesses to my application only? Surely needed for a kind of API key/API secret key to implement Authorization and not simply Authentication.
For example, I strictly don't want to let external command lines or external web sites, accessing the APIs even if they succeeded the authentication step by providing some good credentials.
Worst, they would have no difficulties to access some data that was initially public, meaning without authentication like for instance: taking a list of a precised set of data.
- Seems to be very vulnerable to some known attacks if HTTPS transfers are not ensured.
I heard and read a lot about HTTP BASIC but it seems that it should be avoid: http://adrianotto.com/2013/02/why-http-basic-auth-is-bad/
Then I read about HMAC solution, as Amazon implements, and it seems a pretty good solution; OAuth1 sounding too complicated for simple cases I want.
Should I try to implement the HMAC solution?
Is the HMAC solution really compatible with a browser, meaning allowing user to call for several distinct operations without needing to authenticate each time?
Does it involve tokens exchanges in this case to do this trick?
I would be really happy if anyone could introduce me the concept of HMAC while dealing with a web application/ browser.
Indeed, I struggle to find some documentations about HMAC scheme coupled with browser.
Or perhaps, really trusting an Oauth Solution? ...
I'm meditating on the subject...