Keycloak for coworking identity
Keycloak centralizes identity, SSO, brokering, and federation for internal tools. A coworking operator should begin with one staging application and staff identities, not door access or a whole member estate.
Fit and non-fit
Good fit: a technically operated self-hosted stack with duplicate staff accounts across a wiki, help desk, or booking tool and a need for consistent joiner/leaver controls.
Poor fit: a team without identity, OIDC/OAuth, Linux, Postgres, and break-glass expertise; a direct assumption that SSO secures physical access; or a migration that cannot tolerate identity-provider downtime.
License and cost boundary
Keycloak is OSI-approved open source under Apache-2.0. Software cost is separate from production cost. Budget for compute, Postgres, reverse proxy/TLS, setup and client migration, high-availability and update work, any external extensions, and specialist support. No paid feature or price is inferred from the license.
Record software, hosting, setup, maintenance, plugins/extensions, and support separately; mark each as applicable, not applicable, or unknown rather than assuming a zero cost.
Prerequisites and data map
Define an identity owner, security owner, recovery owner, authoritative staff roster, MFA policy, realm boundaries, client inventory, and break-glass procedure.
| Data | Source | Keycloak use | Exit/fallback |
|---|---|---|---|
| Staff identity | Approved staff roster | User identity | Reconcile to roster |
| Group membership | Role matrix | App authorization claims | Export role matrix |
| Credentials/MFA | User enrollment | Authentication | Recovery process, never informal sharing |
| Session metadata | Keycloak | Security and operations | Retention-limited logs |
Keycloak holds personal data, credential hashes, groups, and session metadata. Payment data is not in scope.
Smallest useful experiment
Follow official documentation to create one staging realm, connect one non-critical application through OIDC, add two staff users, and practice disabling a test user. Prove the app fails safely and the break-glass route works before any production dependency.
Implementation sequence
- Inventory the single pilot application’s current login and emergency access.
- Review deployment, realm, client, OIDC, backup, and upgrade guidance in the official docs.
- Build isolated staging with TLS, Postgres, restricted administration, and monitored availability.
- Configure least-privilege client settings and two test identities.
- Test login, logout, disablement, failed login, recovery, and IdP outage behavior.
- Document joiner/leaver approval, MFA, realm/client review, and break-glass use.
- Complete realm/data backup and clean restore before adding another application.
Security and privacy controls
- Separate administration from routine staff access and protect break-glass credentials.
- Require TLS and an approved MFA policy; restrict redirect URIs and client secrets.
- Minimize identity attributes and group claims released to each application.
- Apply supported security updates and review logs with a defined retention period.
- Review client and realm configuration changes; test recovery outside the primary identity path.
- Keep physical access decisions and member enrollment outside the pilot.
Backup, export, and restore test
Use only officially documented database and realm export/restore methods appropriate to the deployment. Back up Postgres, configuration, realm/client definitions, and required keys while protecting backup access separately.
Restore to a clean isolated environment. Verify both users, groups, client configuration, login, disablement, and break-glass access. Record what secrets or keys need separate recovery. A file existing in backup storage is not a passed restore test.
Integrations and manual handoffs
No integrations are catalog-verified. OIDC to one staging app is the only assumed pilot connection and must follow that app’s and Keycloak’s official docs. HR/staff roster changes remain a manual approved handoff to identity administrators until a separate integration is verified.
Human oversight
People own realm/client reviews, MFA policy, access approval, leaver timing, incident response, and break-glass use. Keycloak standardizes authentication and access changes; it does not decide who should have access.
Operational checklist
- Identity, security, and recovery owners named
- Authoritative staff roster and role matrix recorded
- TLS, MFA, admin separation, and redirect restrictions reviewed
- Pilot app fallback documented
- Disablement and outage tests passed
- Realm/client changes are reviewed
- Database/realm restore passed on clean staging
- Break-glass access tested and audited
Rollback and exit
Preserve the pilot application’s previous authentication until acceptance. Roll back by disabling the new login path, restoring the prior app configuration, revoking the test client, and reconciling identities. Before broader adoption, export realm/client configuration, retain an independent role matrix, and document how every application returns to local or replacement identity without locking out operators.
Verification and unknowns
Snapshot verified 2026-07-17 from Keycloak, the official repository, and documentation.
Unknown until designed and tested: version-specific deployment details, HA sizing, extension licenses, application compatibility, migration behavior, support arrangements, recovery objectives, and regulatory requirements.