I built a small on-call tracker for my team in a few hours, but then spent most of the day trying to restrict access to six specific people. I eventually used a shared password posted in our team chat, which works but feels like a bad solution. Building a complete login system for such a small audience also seems excessive. How do you usually handle authentication and authorization for tiny internal tools?
4 Answers
If your organization already has a central identity provider—such as Microsoft Entra ID, Okta, LDAP, or another OIDC provider—use that instead of creating accounts yourself. Have the tool authenticate through the provider and allow access only to a specific group. You get individual identities, easy offboarding, and no password handling in the app.
If there’s no company identity provider and the app really needs individual accounts, use a well-tested authentication library or hosted login service rather than rolling your own password system. For a very small internal tool, email-based sign-in links can also work: accept only approved addresses and send one-time links. If you keep a shared password temporarily, store it in a password manager instead of team chat, but remember that shared credentials provide no accountability and make offboarding awkward.
For a tool running inside infrastructure you already operate, putting an authentication proxy in front of it can be a good middle ground. An OIDC-aware reverse proxy or ingress can handle login while the application stays simple. You can start by allowing members of an existing group, then add more detailed roles later if the tool grows.
First decide whether access control is merely convenient or genuinely required. If the tool contains sensitive operational or personal data, it needs real authentication and authorization even if only six people use it. If it is low-risk and only reachable through a corporate VPN, the simplest acceptable setup may be an allow-list enforced by the identity provider or network layer. Avoid exposing an unprotected service publicly, and check your organization’s rules before deploying it outside approved infrastructure.
That’s what I’ve done for small team-only services: reuse the cluster or gateway authentication that is already in place. It avoids building another login system, although access should still be limited carefully because anyone with the underlying infrastructure privileges may be able to reach the tool.