0

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?

  • That's exactly how I would/am doing it. My front end always requests "GET /currentSession" on startup. Either you get the current authentication object in return or 401 on which the front end redirects to the login page. – Herr Derb Jul 2 '18 at 9:22
  • I have implemented this flow quite a several times and, the last one I did, I decided to give up on redirections. Definitively, it's not to way to go with SPA + asynchronous calls (IMO). One reason is that server needs to be stateful in order to remember where to go after the login. Unless you do the job on the client-side. The main reason is that allowing the server to redirect what it's not supposed to redirect (client-side status|page) ends up make making the response handling more complex. – Laiv Jul 2 '18 at 14:10
2
+50

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

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.