Single auth URL? Why not authenticate on ANY URL?

Question

Why hello SOers. My question today is about authentication endpoints and the architecture surrounding them.

Most web frameworks and applications I've encountered seem to have a single URL or endpoint to deal with 'authentication' - e.g. processing authentication tokens such as usernames and passwords, and doing something with them.

It seems to me like this causes a lot of follow-on work, like for example if you hit an auth-required URL, the system needs to pass that URL to the authentication endpoint in order to redirect you back there after authentication and authorisation.

Why not simply listen for authentication tokens on EVERY URL endpoint? With a modern MVC framework utilising a PageController or FrontController pattern this should be simple.

Am I missing the downsides of such an approach? Do some frameworks already utilise such a system? Opine me!

Answer 1

Why not simply listen for authentication tokens on EVERY URL endpoint?

Ignoring the word end-pont for a moment, that's what the out-of-the-box Microsoft Forms based authentication does; in the config you specify the parts of the site you want to protect (like the "admin" folder, whatever), you can have as many of these as you like.

When the user hits anything covered by that (as long as IIS pipes it to the ASP.NET processor) they will need to be authenticated (if they aren't already).

I would imagine the ASP.NET MVC works in exactly the same way.

Not sure if that answers your question (?)