Ways to authenticate and redirect with decoupled front-end web application

Question

I have a coupled web application (frontend and api backend served from the same application). It's worked well for our needs but I've been curious about the differences that would go into having a completely decoupled front and backend.

I'm specifically wondering about how handling authentication requests would work with this approach. Right now I have the option of redirecting a request do a different page, i.e. hitting the /dashboard page would redirect you to /login if the token in a cookie doesn't authenticate.

How would that be handled without all request running through a single application?

I'm assuming I'd create a reverse proxy to pass along any requests from the /api path to the backend server. But everything else would be handled by whatever serves the frontend. If I'm thinking about this correctly would each request for a page on the frontend be "unrestricted" in a sense and then after requesting authentication information from the backend handle redirecting to the correct page.

Going back to the /dashboard to /login example, would it follow this flow?

• Users requests /dashboard url
• NGINX serves the static resources needed for the dashboard SPA.
• Frontend JavaScript code requests auth info from a backend endpoint
• If the user's cookie doesn't authenticate, redirect the user to /login through JavaScript.

Am I on the right track or is there a better way to solve this problem?

Answer 1

You would handle it much the same as you do now. Decoupling the Api doesn't mean you have zero server side code on your website.

Specifically you want to be able to deny unauthenticated users access to your javascript, images, html and other content.

You can do this by keeping your current server side authentication code to handle the login and token generation. Once the login has succeeded the token can be read by the javascript and subsequently used to auth requests to the API as well as being passed to the Webserver to authenticate page requests

Answer 2

The way I did it, with an OAuth2 server was this:

1. Client reaches content server.
2. Client does not have an active session, is redirected to authentication server with a callback to content server.
3. Client authenticates and is redirected back to content server with an authentication token.
4. Content server verifies content token with authentication server directly and allows access to client.

Authentication is now on a separate server, but the content server still needs to keep track of the session via a cookie.