Somewhere in your client's office there is a spreadsheet. It has a tab called "Passwords." It contains the login for the shipping portal, the shared login for the inventory system (username: admin, password: the company name plus a 1), and a note saying "ask Carol" next to something called "the AS400." Carol retired in 2022.

Now you are building them an internal tool, and someone asks the dangerous question: how do people log in? Authentication for internal tools sounds trivial until you are the one building it. The temptation, if you have ever written a session cookie, is to roll auth yourself. Register screen, password hashing, reset flow, the works. Please step away from the keyboard.

Here is the direct answer: authentication for internal tools at small companies comes down to three setups that cover roughly 95% of cases. Magic links to the user's work email, Google Workspace sign-in when the company already lives in Gmail, or a network allowlist with a shared PIN for fixed-location tools. Pick one, ship it in a day, and spend the time you saved on the actual business problem.

Authentication for Internal Tools: Three Setups That Cover Almost Everything

Why not roll your own? Because password auth is a tarpit of edge cases dressed up as a weekend project. Reset flows, lockout policies, breach-of-the-week hashing upgrades, and the support tickets. Oh, the support tickets. Every internal tool with passwords generates a permanent drip of "I can't log in" that lands on whoever built it, forever.

All three setups share a philosophy: borrow an identity the user already has, instead of minting a new one they will definitely forget.

The user types their work email, gets a link, clicks it, and they are in. No password exists, so no password can be forgotten, phished from a sticky note, or shared with the whole night shift. The email account is the identity, and securing email is the email provider's full-time job.

Implementation is genuinely small. Generate a signed token with a 15-minute expiry, send it via whatever transactional email service you already use, and set a session cookie on click. Most frameworks have a library for this; you are assembling, not inventing. For a 20-to-200-person company with working email, this is my default, and it has yet to lose an argument.

One gotcha worth planning for: shared mailboxes and forwarded email can leak links. Restrict sign-in to the company domain and keep token expiry short, and this stays a theoretical problem rather than a Tuesday problem.

Session length is the other small decision. Thirty days with a sliding refresh works well for tools people use daily; nobody should have to click an email link every morning just to print shipping labels. For anything touched less often, shorten it. The user's inbox stays the bouncer either way, which is the whole point: you outsourced the hard part to people with a security team bigger than your client's entire headcount.

Option Two: Google Workspace Sign-In

If the company runs on Gmail and Google Calendar, OAuth sign-in is even slicker than magic links. One button, zero emails, and offboarding is handled by the person who already offboards email accounts. When someone leaves and IT disables their Google account, your tool's access dies with it, automatically, at no extra charge.

The killer detail is domain restriction. Configure the OAuth app to only accept accounts on the client's domain, and you have built "employees only" into the login button itself. No user table to maintain, no invitations to send. A new hire can log in before anyone remembers to tell you they started, which is exactly the correct amount of admin work: none.

Microsoft shops get the same pattern via Entra ID, with slightly more configuration ceremony and slightly worse documentation, as is tradition.

Option Three: The IP Allowlist Special

Some tools live in one physical place: the warehouse office, the dispatch desk, the clinic back office. If the tool is only ever used from one network, an IP allowlist plus a shared PIN is honest, pragmatic security. The network boundary does the heavy lifting; the PIN handles "which shift supervisor is this."

This is where running your app on the client's own hardware pairs beautifully with auth design. A tool that only exists on the local network, behind the office firewall, with an allowlist on top, has a smaller attack surface than most SaaS products your client already pays for. Add per-user action logging (more on that below) so the shared PIN does not mean shared accountability.

You will never pitch this setup at a security conference. It is, very often, the right call for a label-printing tool used by six people in one building, and fitting the security to the actual threat is the entire job.

What You Skip, and Why

Internal tools earn simplicity because the threat model is different from public software. Your adversary is mostly accidents and the occasional grudge, not organized crime. So skip, at least on day one:

When the tool grows teeth (payroll data, customer PII, external access), graduate to a managed auth provider and proper roles. That migration is a known quantity, and it is part of the boring, reliable stack laid out in the FDE stack essentials. Start simple on purpose, not by accident.

The Audit Trail You Do Need

The one thing you cannot skip is knowing who did what. Not for paranoia; for the inevitable "why did this order get marked shipped" conversation. Every mutating action logs the user, the timestamp, and the change, in a table you can actually query.

This is cheap. One middleware, one log table, maybe a simple admin page that shows recent actions. With magic links or Google sign-in you already have real identities, so the log is accurate even when the auth is minimal. It is also the feature that ages best: nobody asks for an audit trail in month one, and everybody wants one in month nine when something weird happened to the inventory count.

Build the login in a day, build the log in a day, and move on to the part of the project the client is actually paying for. Authentication for internal tools should be the least interesting thing you ship, right behind the favicon. If you want to see how login fits into a complete internal tool, the Next.js internal tools walkthrough wires magic links into a full app in an afternoon.