Auth via REST API and securing the API itself

Question

I've implemented REST APIs for my application using Jersey 2.x. I went with a REST approach is because I plan to add mobile apps at a later time. Right now it's only a web app. I am at a point where I am thinking about security. There are two things that I need handle.

1. Authenticating and Authorizing users: Right now, I am using HTTP Basic auth over HTTPs. But is there a better way instead of having users send username and password over the wire. I understand it is over HTTPS but I am exploring. OAuth 1.0a comes to mind. Am I on the right track?
2. Securing the API itself: I don't want any other client except for my web app to be in the white list. I will later add my mobile apps to this white list. I am imagining some kind of secret key to identify this client?

I imagine both #1 and #2 above can be done with OAuth 1.0a but they are two different implementations in terms of what is being secured and authorized. Can they both co-exist? Can you provide me with any pointers on how to get started and some examples in the real world?

There is a lot of information out there but security is not my strong suit and I am trying to understand by coding it myself in my own app.

Answer 1

My first suggestion would be for you to look into OAuth 2.0, I'm not going to discuss if it's better or worse than OAuth 1.0a but it does seem to have a wider adoption and as such it will be easier for you to find resources online; OAuth2 also deposits lots of it security capabilities on the shoulders of HTTPS and you seem to already being use that.

In relation to comparing HTTP Basic authentication with OAuth2 I would check this answer for some pros and cons, but in terms of big picture:

With Basic authentication the full credentials are always included in each request, while with OAuth2 it's the access token that is included in each request.

In relation to identifying each client application with a secret key, this is indeed supported in OAuth2, however, if you plan to have (native) mobile applications you have a big challenge ahead because these applications can't really keep secrets (an attacker could reverse engineer your application and find the secret).

In conclusion, for traditional web application it would be easy to ensure that your API only allows access to an authorized user that is indeed using your white-listed application. If you want to open your API to native mobile application you'll have an hard time proving that the call comes really from one of your authorized applications.

For examples on common OAuth2 scenarios I would check Auth0 Architecture Scenarios.