Every new app tends to grow its own login: a password table, a reset email, a lockout rule, maybe two-factor if someone had time. Each one is a little different, and each one is another place where personal data lives.

The OpsAPI demo shows the alternative. The two demo apps, hello-java and hello-php, never see a password and never talk to Google. They send the user to OpsAPI at identity.demo.opsapi.org, which signs them in with Google (or email and a 2FA code), adds them to the demo workspace, and hands back a token that the app checks with a single API call. Connecting another app takes a login redirect and one small callback page, not a new identity system. Everything runs in our own Kubernetes cluster behind our own edge, so user data and running costs stay with us, and there's no per-user identity bill.

What changes for the team

  • One user directory. A person is one account across every app, with a role per workspace.
  • Security in one place. Two-factor codes, lockout after failed attempts, rate limits and the audit trail are OpsAPI's job, not each app's.
  • A small cost per new app. Allow the app's address, add a login redirect and a callback page. No SDK, no client registration.
  • Any language. The demo has Java and PHP side by side; anything that can make an HTTP call can join.
  • Your infrastructure. The sign-in service and its database run where your other services run.

Keep the admin side off the internet

Customer-facing apps have to be public. The dashboards that run the platform don't. In production we recommend putting every admin surface (the OpsAPI dashboard, the edge proxy's admin, the secrets vault, monitoring and the Kubernetes API) behind a VPN or a zero-trust access broker such as Zscaler Private Access, Cisco Secure Client or a self-hosted WireGuard VPN, with access granted per app to named groups. OpsAPI's own sign-in, emailed codes and roles still apply on top.

Customers reach public apps; staff reach admin dashboards only through a VPN or zero-trust brokerCUSTOMERSCustomerany browserPublic appshello-java, hello-phpOpsAPI sign-inpassword + code, or GoogleSTAFFStaff devicemanagedVPN / ZTNA brokerper-app access policyAdmin dashboardsOpsAPI admin, edge, vault, metricsAnyone elserefused before it reaches a login page
Two doors: customers sign in through OpsAPI on public apps; staff reach admin dashboards only through the broker, then sign in again with MFA.

The public demo is the exception on purpose: its dashboard is open so you can look around with a read-only demo account. It still requires a sign-in, and the demo account can't change anything.

Honest limits

  • OpsAPI isn't an OpenID Connect or SAML provider. Apps use its redirect-and-token contract, so off-the-shelf OIDC clients won't plug straight in.
  • Running it means running it: a PostgreSQL database, backups, upgrades and monitoring are yours.

See it working

Open the live demo, sign in to the Java app, then open the PHP app. The sign-in flow technote has every step for your developers.