General authentication for website and RESTful API

Question

Goal. My server should direct non-users to the landing / home page and register users in a real application. When the application is downloaded, it will make authenticated HTTP RESTful API requests (via Ajax).

I have a RESTful API that needs authentication. On another server, I have my website, which also requires authentication, so I can determine whether to show the landing / home page for non-users or the application for registered users.

Initially, I thought that it would be enough to implement HTTP Basic Auth for the RESTful API. However, in order to get authentication for my website, I also need to configure authentication there, which would mean duplicating low-level code to verify credentials in the database in both the REST API and the website’s servers.

As an alternative, I wondered if the website can authenticate through the RESTful API. For example, in my request handler for POST /login I could make a GET request to my API by passing user credentials from the request body. If the request returns 200 OK , I can sign up for a user session, thereby authenticating them. From there, Ajax requests to the REST API should be authenticated with the same credentials, so I could:

• set a cookie containing credentials, which allows JavaScript to get credentials before executing the request (OK with SSL?)
• reset credentials in served HTML for a web application, allowing JavaScript to get credentials before executing the request (OK with SSL?)
• API proxy through the web application server, where can I get the credentials from the session and add them to the Authorization header of the proxied request?

Alternatively, I suppose I could just share the session between the two servers, although Ive heard that this is bad practice for RESTful design.

What would be wrong with that? Is there a better way to achieve my goal?

Answer 1

I recently implemented something similar to this (assuming I understand you correctly), and there seemed to be several viable options.

• Does the server side of your web application always authenticate with a specific username / password when accessing the REST API, ensuring that your web application is always trusted and that users are supposed to log into the web application correctly if the request authenticates as an application.
  • Pros: Ease of use, ease of perception, simple extension for other applications (we had a CLI that also accessed the same REST API).
  • Cons: It is not possible for the REST API to know which user it is actually accessing. If a trusted client is hacked, the entire system is compromised.
• Ask the server side of your web application to save user data in the session and authenticate using user credentials each time the REST API is accessed.
  • Pros: It’s quite easy to implement (although some authentication mechanisms make it difficult to save a user’s password - for good reason). The whole procedure is transparent to the REST API.
  • Cons: now you save (for all purposes and purposes in text form) the username and password of the user in a web server session - one of the most important goals for an attack on the system.
• Create an authentication system in the REST API that authenticates the request with authorization of the username and password and returns a token valid for a limited time.
  • Pros: it is safer if your web application is compromised, you do not provide the attacker with username / passwords of users, but instead allow them limited time access.
  • Cons: much harder to implement. You may need to deal with token timeouts. For purists, this also means that your REST implementation (or at least the authentication system) will apparently be "stateful".

What you need to implement will depend on your situation. Personally, I would definitely go with a safer option (the latter), but due to external constraints we were forced to implement the first option in our specific case (with a promise, we revise it and update it later - unfortunately, it never comes back later).

Answer 2

I think your approach using basic HTTP authentication in a REST service and authenticating your application with a service is excellent. The only caveat (which I'm sure you know) is that your REST service should work over SSL, since basic HTTP authentication is not very secure - the username and password are only Base64 encoded.