Casdoor security boundaries: tenants, secrets, protocols, and failure modes
A security-focused review of Casdoor covering multi-tenancy, OAuth/OIDC and SAML failure modes, SCIM tokens, MFA recovery, webhooks, databases, and agent authorization boundaries.
Casdoor improves the security posture of teams that need a self-hosted identity platform, but only when its boundaries are explicit. A broad IAM product can centralize OAuth/OIDC, SAML, CAS, LDAP, SCIM, MFA, organizations, applications, providers, REST APIs, SDKs, Swagger, webhooks, and agent authorization. Centralization helps governance. It also makes mistakes more expensive.
The official project is casdoor/casdoor, Apache-2.0 licensed, with master as the default branch. The latest release at research time was v3.121.0 on 2026-07-21. The repository is primarily Go with a React front end; go.mod uses Go 1.25.0 and toolchain go1.25.8. Beego, Casbin, and the MCP Go SDK are part of the technical surface. Security issues should be reported to admin@casdoor.org, according to the project’s security information.
Tenant boundaries must be tested, not assumed
Casdoor supports organizations and multi-tenancy. That does not remove the need for tenant-boundary tests. Operators should verify that users, applications, providers, certificates, roles, policies, tokens, webhooks, and logs do not leak across organizations. Admin roles should be scoped carefully. A global admin account used for routine application work is a governance smell.
For agentic systems, tenant boundaries are even more important. An agent may run in the background and combine identity, retrieval, tool calls, and API writes. The platform must be able to answer: which tenant did the agent act for, which user or service delegated authority, which policy allowed the action, and which external tool was called?
Secrets are not configuration comments
Casdoor deployments contain client secrets, database credentials, SMTP or provider credentials, webhook secrets, SCIM tokens, and signing material. These belong in a secret manager or protected runtime environment, not in public images, copied examples, or chat transcripts. Rotation should be planned before incident response requires it.
# Safer deployment pattern
CASDOOR_ORIGIN=https://iam.example.com
CASDOOR_DB_DSN=${SECRET_DB_DSN}
CASDOOR_CLIENT_SECRET=${SECRET_CLIENT_SECRET}
CASDOOR_WEBHOOK_SECRET=${SECRET_WEBHOOK_SECRET}
OIDC and SAML fail differently
OIDC failures often involve issuer mismatch, redirect URI mismatch, audience errors, expired signing keys, cookie SameSite/Secure mistakes, or proxy header confusion. SAML failures often involve certificate rotation, entity ID mismatch, clock skew, assertion mapping, or logout semantics. Treating both as “SSO is broken” slows recovery.
A production runbook should include example decoded ID token claims, expected issuer, allowed redirect URIs, current signing keys, SAML metadata location, certificate expiration dates, and a rollback path for provider changes. Never debug by temporarily allowing wildcard callbacks in production.
SCIM and webhooks are write paths
SCIM can create, update, disable, and group users. Webhooks can trigger downstream automation. Both should be considered write-capable integration surfaces. Use dedicated tokens, minimum scopes, source verification, retry limits, idempotency keys where applicable, and audit logs. A leaked SCIM token can become a lifecycle attack, not merely an information disclosure.
MFA recovery is a security process
Casdoor supports WebAuthn, TOTP/MFA, Face ID, and enterprise providers such as Google Workspace and Azure AD. MFA improves security only if recovery is controlled. Help-desk reset procedures, backup codes, lost device workflows, emergency admin accounts, and break-glass logging must be documented. The weakest path to a privileged account is often recovery, not login.
Failure boundary
Casdoor should fail closed for admin access, token issuance, provider mismatch, callback mismatch, and tenant ambiguity. It should fail loudly for webhook delivery, SCIM synchronization, and database connectivity. It should not leak secrets in logs or error pages. The security benefit of self-hosting appears only when operators own these boundaries instead of assuming the product handles them automatically.