One IAM, one tenant, one sign-in
The Osage ecosystem runs on a single IAM tenant. Every application — the store, the exchange, the docs, the community, the explorer — authenticates against iam.osage.id and presents the same login at osage.id. There is no second user database; there are no per-app accounts.
Each application is registered in IAM under the osage-<app> naming convention — osage-exchange, osage-store, osage-docs, osage-network, and so on. The host application redirects to osage.id with ?return_url=…&app=osage-<app>; the portal issues the session and bounces the user back.
How sessions cross domains
Cookies are scoped per parent host (.osagebrothers.com, .osage.shop, etc.). Cross-TLD continuity is handled by a token-exchange round trip back through osage.id; the user never re-types a password. The session is the same session.
What you control
- Display name, contact details, language, and timezone.
- Two-factor authentication — TOTP and hardware keys (WebAuthn).
- Linked wallets, used only by the capital and on-chain properties.
- Active sessions and connected devices, with one-click revoke.
- Per-application access — revoke or grant any
osage-<app>independently. - Data-export and account-closure requests, served within 30 days.
Built on Hanzo IAM
Osage ID is the Osage configuration of Hanzo IAM (~/work/hanzo/iam) — the same identity stack that powers the rest of the Hanzo platform. Secrets in Hanzo KMS (kms.osage.id) only; plaintext does not exist in this ecosystem.
For sovereign partners
Tribal nations and partner governments who wish to issue and verify their own credentials on the same infrastructure should contact Osage NGO and the Osage ID team. We co-deploy; we do not custody.
What we don’t do
We do not sell, share, or rent identity data. We do not run an advertising network. We are not a social graph. Osage ID exists to let you sign in once and to keep your account portable across the ecosystem — that is its only job.