Sooner or later, every small internal tool hits the same question: who is allowed to use this? A dashboard for the sales team, a web form for HR, an app a colleague put together with an AI assistant over lunch. The fastest answer often looks like a users table and a password field. It works on day one. The trouble starts later.
This post walks through the two standards behind almost every "Sign in with..." button, OAuth and OpenID Connect (OIDC), why a homemade login is riskier than it looks, and how we approach the problem at cyantula.
OAuth: a valet key, not an ID card
OAuth 2.0, defined in RFC 6749, is about authorization, specifically delegated access. It lets an application act on your behalf against some resource, without you handing over your password.
Think of a valet key. The parking attendant gets a key that starts the car but does not open the trunk. In OAuth terms, an app asks for permission ("read this user's calendar"), the user approves it at their identity provider, and the app receives an access token with a limited scope and lifetime. The app uses that token to call an API and never sees the password.
What OAuth on its own does not do is tell the app, reliably, who the user is. An access token is meant for an API, not as proof of identity.
OIDC: the identity layer on top
That gap is filled by OpenID Connect Core, a thin layer on top of OAuth 2.0 that adds authentication: proof that a specific person just signed in.
The key addition is the ID token, a signed JSON Web Token issued by the identity provider. It carries claims your app can check: who issued it, a stable identifier for the user, which app it was meant for, and when it expires. The big workplace identity providers speak OIDC natively; Microsoft, for example, documents how the Microsoft identity platform implements it, and Google documents the same for its accounts, Workspace included.
A short way to remember it:
- OAuth answers "what is this app allowed to do?"
- OIDC answers "who is this person?"
Why a homemade login is riskier than it looks
Authentication mistakes are common enough that OWASP gives them their own category in its Top 10, A07: Identification and Authentication Failures. The list of weaknesses there reads like a description of a typical quick login: weak or default passwords allowed, weak forgot-password flows, plain text or weakly hashed password stores, missing multi-factor authentication, and sessions that are not invalidated properly. The OWASP Authentication Cheat Sheet shows what doing it properly involves. For internal apps, the usual weak spots are:
- Password storage. Passwords need a slow, salted algorithm built for the job (such as Argon2id or bcrypt), not plain text or a fast general hash.
- Resets. "Forgot password" flows need expiring, single-use tokens and must not reveal which accounts exist.
- MFA. Your company login probably enforces multi-factor authentication. A separate password in a side app quietly bypasses it.
- Sessions. Cookies need the right flags, sessions need to expire, and logout should actually end the session.
- Offboarding. When someone leaves, IT disables their company account. A password in a forgotten side app is not on that list, so access keeps working.
None of this is exotic. It is just a lot of work, and your identity provider has already done it.
What "behind the company login" means
Instead of checking passwords, the app hands sign-in to the identity provider your company already uses. The user sees the familiar login screen and MFA prompt, the provider confirms who they are, and the app receives a verified identity. You can wire OIDC into each app with a maintained library, following the IETF's OAuth 2.0 Security Best Current Practice (RFC 9700): the authorization code flow with PKCE, no implicit flow, no "send us your password" grant. Or you can put an authenticating gateway in front, so the app contains no login code at all.
A short checklist for builders
- Don't store passwords in your app.
- Use the company identity provider, through a maintained OIDC library or a gateway.
- Use the authorization code flow with PKCE.
- Validate ID tokens: signature, issuer, audience and expiry.
- Decide who has access explicitly, not "anyone with a company account".
- Keep client secrets out of code and chat.
- Check that disabling a company account removes access to your app.
How cyantula solves this
That checklist is reasonable for one app. With ten or twenty small tools, built by different colleagues (some with AI), it becomes a lot to get right every time. Cyantula takes the gateway route and makes it the default.
Every internal app sits behind an authenticating gateway that uses your company's existing login, for example Google Workspace or Microsoft. The app never sees or stores a password and never implements login. The gateway authenticates the colleague, strips any identity a client tries to forge, and passes verified identity headers plus a signed identity token into the app. Each app gets its own URL and its own access list: a class, a team or an individual colleague.
Mapped to the problems above:
| Problem | How cyantula handles it |
|---|---|
| Password storage | The app has no passwords to store |
| Resets and MFA | Stay with your identity provider |
| Forged or spoofed identity | The gateway strips it and passes only verified identity |
| "Anyone with an account" | An access list per app |
| Offboarding | Disable the account and access to all apps is gone |
| Hosting and ops | Runs on your own VM, with blue/green deploys, rollback and backups |
| AI agents building apps | MCP, so agents publish and manage apps behind the same door and access list as people |
For builders, publishing stays simple: a repo, a zip or a conversation, with a preview before a change goes live. The security work lives in one place instead of being reinvented in every app.
cyantula is free to install for one app builder and up to five users. If this is a problem you recognise, you can read more at cyantula.app.