Hanzo Identity
The sign-in your users actually see. Hanzo IAM is the service; Identity is what stands in front of it — the sign-in page, the sign-up, the account screen, and the SDK that puts them in your app. Your application redirects, a person signs in, and your code gets back a signed token. It never sees the password.
Signing in
A password, a passkey, or a Google or GitHub account. A second factor when the organization asks for one.
What the token carries
Who signed in, which organizations they belong to, and the role they hold where they asked to act.
One sign-in, every app
Sign in once and the session is good across every app in the organization, including ours.
What it does
Standards, not a proprietary protocol. If your framework can read an OpenID Connect discovery document, it can already talk to this.
A second factor
An authenticator app, a code by SMS or email, or a passkey. Enrolment sends the material and then demands it back before it writes anything, and the destination is never taken from the request — an enrolment that let the caller name the phone would enrol the attacker's.
Accounts and membership
Create people, put them in an organization, give them a role there. SCIM 2.0 does the same thing from a directory you already run, so joiners and leavers arrive without a script of your own.
Single sign-on
Every application registers under its own client id and redirects to the same authorize endpoint, so a person who is already signed in comes straight back with a code and never sees a form twice.
Roles that travel
A role is granted at a place — an organization, a workspace under it, a single project. The token carries the one that applies to the request, so your service decides without asking us anything.
Passkeys
A WebAuthn credential registered to the account, unlocked by whatever the device already uses — a fingerprint, a face, a PIN. Nothing that can be phished, because there is nothing to type.
A record of what happened
Actions are written once to an append-only log scoped to the organization they happened in. The write path exists; there is no edit path for normal operation, which is the point of keeping one.
Running it for a large organization
The same service, wearing your name, on hardware you choose.
Where the data sits
An organization is a tenancy boundary, and the boundary is enforced by the code that reads the token rather than by a column somebody has to remember to filter on.
- •Enterprise security with GDPR and privacy controls
- •Self-host it, in your own region, on your own cluster
- •One Go binary, embedded SQLite by default — nothing to run beside it
Bring the identity you already have
Point Identity at your own issuer and it becomes the entry point without becoming the record.
- •Federate to any OpenID Connect issuer by naming its discovery URL
- •SCIM 2.0 provisioning, so joiners and leavers arrive from your directory
- •White-labelled by hostname — your mark on your domain, never ours
Signing up your customers
An organization can hold its own customers as sub-organizations, so a business you serve manages its people without any of it reaching yours.
- •Sign in with Google or GitHub, or with any issuer you add
- •A consent screen the person has to pass before an app gets a token
- •Org admins manage their own members without platform access
What you write
Almost nothing. Nobody should be hand-rolling OAuth in 2026, and with this you do not.
- •One SDK with an entry point per runtime — server, React, browser, Next.js, Passport
- •An OpenAPI 3.1 description generated from the handlers themselves
- •The sign-in page is hosted and already built — you send people to it
Add sign-in
Register the app, set the callback your framework already uses, install the SDK. That is the whole integration.