Single sign-on means a user authenticates once and then moves freely across many separate applications without logging in again. The mechanism that makes this safe — rather than merely convenient — is the cryptography of the tokens passed between those apps, and the controls layered on top of the first login.
What single sign-on actually is
SSO is a shared session. The user signs in to one identity service, and every application in the family trusts that service to vouch for who the user is. The applications themselves never see a password. They receive a signed token that asserts an identity, and they verify the signature before honouring it.
The shared session is carried by a cookie scoped to the parent domain rather than to a single app. A session established at the identity service is therefore visible to every subdomain application under the same parent domain. The user signs in once and the cookie travels with them. HQ Auth uses parent-domain session cookies for exactly this reason, so one login is shared across every subdomain app in the suite.
The practical effect: there is one place to sign in, one place to sign out, and one place to revoke access. The alternative — a separate login per tool — multiplies passwords, multiplies the attack surface, and leaves no single point at which access can be cut.
Why asymmetric (RS256) signing matters
A token is only useful if an application can trust that it was issued by the identity service and not forged. There are two ways to sign a token.
- Symmetric (HS256) uses one shared secret to both sign and verify. Every application that can verify a token can also mint one, because verification and signing use the same key. A single compromised app leaks the ability to forge tokens for the entire family.
- Asymmetric (RS256) uses a key pair. The private signing key never leaves the identity service. Each application receives only a read-only public verification key. An app can confirm a token is genuine, but it can never create one. A compromised app cannot forge identities for any other app.
This is the difference between handing every tenant a master key and handing them a key that only opens locks, never cuts new ones. HQ Auth signs with RS256: the private key stays in one place, and per-app verification keys are distributed so each app verifies tokens locally without ever calling home on the critical path.
Short-lived access plus rotating refresh
Even a correctly signed token is a liability if it lives forever. A stolen token is a stolen session for as long as the token is valid. The standard mitigation is a two-token model.
- A short-lived access token — valid for 15 minutes — is the credential an app actually checks on each request. If it leaks, it is useless within minutes.
- A longer-lived refresh token — valid for 7 days and rotating — is presented only to obtain a fresh access token. Rotation means each use issues a new refresh token and invalidates the old one, so a captured refresh token that is replayed is detectable and can be cut off.
The blast radius of any single stolen credential is bounded by these two windows. Compare this to a long-lived session token that, once captured, grants access until a user manually logs out somewhere they may never return to.
What TOTP 2FA and magic links add
The first factor — something the user knows — is a password. Two further mechanisms strengthen or replace it.
- TOTP two-factor adds something the user has: an authenticator app generating a rotating six-digit code. Even a fully compromised password is insufficient without the device. This is the single highest-leverage control against credential stuffing and phishing of static passwords.
- Magic-link sign-in replaces the password entirely with proof of inbox control. The user receives a one-time link by email; clicking it establishes the session. There is no password to phish, reuse, or leak in a breach.
HQ Auth supports email and password, OAuth through Google, GitHub, Apple and Microsoft, TOTP two-factor, and magic-link sign-in — alongside brute-force protection, a full authentication audit trail, and device and session revocation so a lost device can be cut off without resetting everything else.
Tying it together
Good SSO is not one feature but a stack: a parent-domain session for the shared experience, asymmetric signing so trust flows one direction only, short-lived rotating tokens to bound exposure, and a strong second factor at the front door. Remove any layer and the convenience of one login becomes a single point of failure. Keep them all and one login becomes the most defensible part of the system.
Takeaway: Single sign-on is safe only when the cryptography is asymmetric, the tokens are short-lived, and a second factor guards the first login — convenience without those three is just a shared password with extra steps.