Home > Software engineering >  Should you always use "redirect flow" when building an authentication system, or should yo
Should you always use "redirect flow" when building an authentication system, or should yo

Time:01-05

In most websites I see today, the login system works as follows:

  1. Click on a "login button" in the navigation menu and be redirected to a "login page"
  2. Fill in your credentials and be redirected to your "profile page"
  3. Then from there you have to navigate back to were you originally came from.

This seems like an unnecessarily long proccess which requies at least 3 full page refreshes before you get to the resource you wanted. Especially in the context of an ecommerce website where your conversion-rate is directly dependent on less loading time and fewer clicks to get to the checkout page.

If on the contrary, you use fetch, here is how the system flow works:

  1. Click on a "login button" in the navigation menu and get a dropdown menu or popup box with the login form
  2. Fill in your credentials and send a fetch request to your server which in turn sends a response with the user object.
  3. Handle that respons with JS and update the few components on the page that need updating.

This requires minimum loading time, no refreshes, let's you stay on the page you were originally on, eliminating any navigation confusion. With this in mind, why does bearly any website do this? I have build this system already, but am scared to use it (maybe I have too much of a sheep mentality), but seriously, are there any security concerns or something I am overlooking here?

CodePudding user response:

An "old-fashioned" login page is the lowest common denominator that is guaranteed to work: with old browsers, without javascript, with assistive technology, with password managers. Also a redirect flow is more or less necessary when you want to implement SSO.

Given the importance of the login step in any application, it's not a bad idea to dedicate a separate page to it. This also trains users not to enter their credentials anywhere, but to be aware about the location.

Depending on your application, it also might be relevant to use a separate page for being able to harden its security, e.g. by running less scripts, not serving adverts, disabling third-party scripts etc.

All that said, let nothing get in your way of adding some unobtrusive javascript to the login page or progressively enhancing your login button to show only a popup instead of navigating to the login page - if that really helps your conversion rate, and as long as nothing breaks the basic functionality.

CodePudding user response:

There are a few reasons why many websites do not use the login system you described:

  1. Compatibility with older browsers: Some older browsers do not support JavaScript or have it disabled, so a login system that relies on JavaScript might not work for all users.

  2. Security concerns: While using fetch to send a login request to the server can be more efficient in terms of page loading times, it can also introduce security vulnerabilities if not implemented correctly. For example, if the login form is not properly sanitized, a malicious user could potentially inject code into the form and send it to the server, which could lead to security breaches.

  3. User experience: Some users may prefer the traditional login flow where they are redirected to a separate login page. This can make it more clear to the user that they are logging in and provide a sense of security.

Overall, it is important to consider the trade-offs between efficiency and security when designing a login system. It might be worth considering implementing your login system in a way that works for both older browsers and modern browsers, while also keeping security in mind.

CodePudding user response:

Most big websites have a SSO (single sign-on) solution because they usually provide more than one service. For example in Google you have Gmail, YouTube etc... That's why they have a separate login page and each of the services will redirect you to it so you can log in and get the cookie. It would be too much trouble to have the same security logic copied in multiple places. Same for the profile information. It is shared for all services. For a small site you can use fetch and avoid the page reloads as long as it works for you.

  • Related