I am fairly new to web development, and I am learning to build web applications. I am facing a problem figuring out how to set up authentication mechanisms for a multi-user application. Let me provide some details about the architecture:
Here I have two web servers – Front-end application (written in Angular) and a back-end REST API. The two exist separately to have a more decoupled system (back-end provides the data, front-end presents it), as well as to allow third-parties to implement their own client-side applications. I am not sure if it is relevant, but the back-end API is a PostgREST web-server sitting on top of a PostgreSQL database.
As I mention before, this is a multi-user application, so I would also like to set up authentication for clients. In the context of my architecture it means setting up authentication for www.domain.com to api.domain.com as well as for client to www.domain.com. I think that it makes more sense to use token-based authentication to access the back-end API, as it will not be accessed by browser-based client directly. As for the authentication on www.domain.com I think I have options to either go for token-based or session-based authentication. If am getting it right the authentication process should look something like this:
The problem is that I do not understand how to set up the translation of client–www.domain.com authentication to the one between www.domain.com and api.domain.com. What kind of authentication mechanism is most suitable for the browser-frontend communication in this situation? How to "forward" the authentication to the back-end API? Is there another way of achieving this?
Best Answer
The situation is quite common. The clients of the API are not the actual people using an application, but rather the applications between the final user and the API—your web application, or an Android/iOS application, or a batch script. All those API clients, however, can access users' data, which creates the problem: the API is not expected to give unlimited read-write access to users' data to any client willing to access it.
Why not? For two reasons:
If the API is public, i.e. anyone can write a client, you're giving access to users' data to everyone. This is not acceptable in nearly every case.
If the API is not public, i.e. you are the only one to be able to add clients, then you'll quickly find yourself limited in terms of which client can be created. Web application would be OK, as it's hosted on your servers; everything else is not. This means that it will be impossible, for instance, to have client apps for mobile devices or even applications for desktop PCs, since the exchange between such client and your server can easily be decrypted, analyzed and tampered with (HTTPS won't help at all here, since the owner of the device would be able to generate a custom root certificate).
This means that it belongs to the user to confirm that he authorizes a given application to access his data through the API. You can see this sort of interactions a lot if you use applications which need to access your Google Drive or your Facebook data: Google and Facebook respectively will ask you to confirm that you want to give access to your data for a given application, explaining what exactly the application will be able to access, and it belongs to you to accept or refuse.
This, however, has one limitation: if the users come to your https://www.example.com/, and are welcomed with a screen from https://api.example.com/ asking whether http://www.example.com/ can access their data or not, they won't understand. This means that you should have a list of trusted clients: in your case, the web application would be a trusted client of the API, being granted unlimited access to the data of every user.
This doesn't mean, however, that you should necessarily
POST http://www.example.com/login. This is one way of doing it, but a simpler approach would be to use OpenID or OAuth 2.0. This became a de facto standard way of authenticating users, and if you rely on somebody else, such as Google, to do the authentication, you get a huge benefit of not having to deal with passwords.