Adding login to an app or an API is something developers keep doing over and over. You pick an identity provider, set up configs, implement a login flow, validate tokens, handle errors, add logging, and integrate it all into an existing system. None of this is especially unique per project, but it’s still a lot of work each time.

To get a login flow working, a developer typically needs to get access to an app or API at the chosen identity/auth provider, choose which provider to use, set up separate dev and prod configuration, and make sure the app and server can read that configuration correctly. This means wiring environment variables, config files, secrets, and making sure everything is consistent between environments.

Then you have to program the actual login flow. That usually includes a login page or button, redirecting the user to the provider, handling the callback endpoint, dealing with state, and setting up sessions or tokens. On the server side, you need components or endpoints to receive and process the login response and connect it to how your app represents users.

On top of that come all the cross-cutting concerns. You have to code token validation (for example verifying JWT signatures, issuer, audience, expiry and scopes). You have to handle error situations such as invalid tokens, expired sessions, misconfiguration, or provider errors. You need logging and observability so you can see when login fails and why. Finally, you must integrate everything into the existing application or system, protecting endpoints, checking roles or permissions, and mapping identities to whatever domain model you already have.

Most of these tasks are very similar from project to project. Developers keep deciding and implementing the same things repeatedly. The real choice in many cases is only which id/auth provider to use and which flows to support. The rest is largely the same glue code and setup. There is little reason to solve all of this from scratch every time.

Instead of re-implementing everything, you could use a high level standard component for login. In such a model, the only thing a developer really needs to decide is which identity/auth provider to use and provide the minimal configuration for it. The component would handle dev and prod configuration, reading config in the app and on the server, the login flow (pages and server parts), token validation, error handling, logging, and simple hooks for integrating with existing applications.

The goal is to avoid manually setting up and coding all of these pieces in each new project. By treating login as a reusable, high level standard component, you reduce the work to what is actually necessary: choosing a provider and specifying the few details that are truly specific to the application. Everything else becomes implementation detail that the component takes care of, instead of a new “doing job” for every single app.