Single sign-on: why every app we host shares one login

What single sign-on is

Most software ships with its own idea of users: its own signup page, its own password table, its own rules. Give a business five apps and you have five little identity systems, five passwords per person, and five places for things to go wrong.

Single sign-on (SSO) removes the duplication. Instead of every app deciding for itself who you are, apps delegate the question to one identity service. When you open an app, it redirects you to that service; you prove who you are once; the service hands the app a signed token that says "this is genuinely Sam, and Sam is allowed in". The app trusts the token because it is cryptographically signed, not because it holds a password of yours. It never sees your password at all.

This works across wildly different software because it runs on open standards: OpenID Connect and OAuth 2.0 for modern applications, SAML 2.0 for the older enterprise world. Any app that speaks one of those protocols, which today is most serious software, can join the same login.

The buying question: how many passwords are my staff juggling?

If your team runs on separate logins per app, three costs accumulate quietly.

The first is the passwords themselves. People are asked to hold a strong, unique password for every system, so they do the human thing: reuse them, simplify them, write them down. Every extra password is another chance for a phishing page to harvest something that works elsewhere.

The second is joiners and leavers. Onboarding someone means creating accounts in every app; offboarding means finding them all again. The account nobody remembered, still active months after someone left, is one of the most common findings in any security review.

The third is invisibility. With five separate password systems there is no single answer to "who signed in to what, and when?": each app keeps its own partial log, if it keeps one at all.

Single sign-on inverts all three. One strong credential, guarded properly, with multi-factor authentication enforced in one place. One account to create on day one and disable on the last day, with every app following automatically. One log of authentications across the estate. This is why we treat SSO as part of the security architecture, not a premium add-on.

How Node runs it: Keycloak, one realm per customer

The identity service behind every Node workspace is Keycloak, an open source identity and access management platform originally developed at Red Hat and now a Cloud Native Computing Foundation incubation project. It implements the standards above, handles multi-factor authentication and session management, and federates with external directories.

Two details of how we deploy it are worth knowing.

Every customer gets their own realm. A realm is Keycloak's unit of complete isolation: your users, groups, credentials and access rules live in a realm that is yours alone, not rows in a shared user table. That isolation is enforced at the identity layer across every app, which is part of how tenants are kept structurally separate on the platform; the wider picture is in How the Node Platform is built.

Your existing login can come with you. If your organisation already lives in Microsoft Entra ID, Google Workspace or an LDAP directory, we federate it in rather than making people learn a new password. Your directory remains the source of truth; Keycloak brokers the sign-in and applies your rules on top.

The same identity layer extends beyond web logins: our API gateway checks every API call against Keycloak too, so a script or an AI agent is identified and authorised the same way a person is. And because we run our own company on this platform, our own staff sign in to our own tools through exactly this arrangement, every working day.

---

Frequently asked questions

Is one login not riskier than many?

It concentrates risk, which is exactly why it is safer in practice. A password per app produces reused, rarely rotated passwords scattered across systems with wildly different security standards, and no single place to watch. One login means one place to enforce a strong password, one place to require multi-factor authentication, one place that logs every sign-in, and one account to disable when someone leaves. You defend one well-built door instead of twenty assorted ones.

Can my staff keep signing in with their Microsoft or Google accounts?

Yes. Keycloak federates with existing identity providers, including Microsoft Entra ID, Google Workspace and on-premise LDAP or Active Directory, so your current directory stays the source of truth and nobody learns a new password. Keycloak brokers the login and applies your access rules on top.

What happens when someone leaves the company?

You disable one account, and every app in your workspace stops accepting them, because each app checks with the identity service rather than keeping its own password list. Without single sign-on, offboarding means finding every account the person ever had, and the one you miss is the one that turns up in a security incident.

Who maintains Keycloak?

Keycloak is an open source identity and access management project, originally developed at Red Hat and now a Cloud Native Computing Foundation incubation project with a large community behind it. There are no per-user licence fees, which is one reason we can wire it into every workspace as standard rather than selling logins by the seat.

Do all apps actually support single sign-on?

The apps we host do, because we configure them that way before you see them. Keycloak implements the open standards most software already speaks (OpenID Connect, OAuth 2.0 and SAML 2.0), which covers modern web apps, older enterprise software and mobile apps alike. When you add an app from our catalogue, arriving pre-connected to your login is part of what deploying it means.