Identity Broker Security Posture
Unstract delegates all authentication to Auth0, an industry-standard identity platform (now part of Okta). For Enterprise SSO, your organization's Identity Provider (IdP) is connected to Unstract's Auth0 tenant as an Auth0 Enterprise Connection. Supported and production-deployed IdP integrations span SAML, OIDC, Azure AD / Entra ID, and Okta Workforce — all four connection types run in Unstract production today. (Auth0: Enterprise Connections)
In this model Auth0 is an identity broker: when a user signs in, Auth0 redirects them to your IdP, your IdP performs the actual authentication, and Auth0 relays the resulting identity to Unstract. As Auth0's documentation puts it, "Auth0 sits between your application and its sources of users, which adds a level of abstraction, so your application is isolated from any changes to and idiosyncrasies of each source's implementation," where a connection is "the relationship between Auth0 and a source of users." (Auth0: Identity Providers)
Addressing common security concerns
"We must share a client ID/secret with a third party."
The answer depends on the connection protocol:
| Protocol | Credential model | Notes |
|---|---|---|
| SAML | No shared secret. Trust via X.509 signing certificate. | Auth0 is the SAML Service Provider; you provide your IdP's public signing certificate so Auth0 can verify signed assertions. (Auth0: Connect to SAML IdPs) |
| OIDC / Azure AD / Okta | A client ID/secret you mint inside your own IdP. | The credential is created in your IdP and scoped to the Unstract app registration only. It lets Auth0 initiate authentication; it grants no access to your resources, and you can rotate or revoke it unilaterally at any time. (Auth0: Connect to OIDC IdP) |
"We must track CVEs and their impact in Auth0."
Brokering through a managed platform reduces your vulnerability-management surface compared with self-hosting an SSO broker or federation gateway, which you would otherwise have to patch and audit yourself. Auth0 operates under a shared-responsibility model in which platform patching and vulnerability management are Auth0/Okta's responsibility.
This is backed by independently audited attestations, renewed annually:
- SOC 2 Type II — annual audit by an independent auditor.
- ISO 27001 / 27017 / 27018 — annual audit by an independent auditor.
- CSA STAR certified.
- HIPAA / HITECH — Auth0 acts as a Business Associate.
- PCI DSS compliant deployment models available.
- GDPR ready.
Further information is available in the Auth0 data privacy and compliance documentation. (Auth0: Data Privacy & Compliance)
"Auth0 is only a broker, not our IdP — it authenticates our ID token and then issues its own token."
This is an accurate description of brokered federation and is by design — the same pattern used by Azure AD B2B and Okta org-to-org. The security properties that matter are preserved:
- Your IdP remains authoritative. Auth0 never stores your users' credentials and cannot authenticate a user on its own; it only relays an authentication performed by your IdP. Deprovisioning a user in your IdP locks them out of Unstract.
- Your MFA, conditional-access, and risk policies continue to apply, because authentication occurs at your IdP.
- Unstract receives identity claims only — never your data. The authenticated session carries identity attributes (email, a stable user identifier, and group memberships used for role assignment). The documents and data you process in Unstract never pass through Auth0.
Defense-in-depth, as deployed
Beyond the platform attestations above, Unstract's Auth0 tenants are configured with the following controls (managed as version-controlled infrastructure-as-code):
- Asymmetric, signed tokens. Application tokens are signed with RS256 and verified against Auth0's published JWKS — no shared symmetric signing key.
- PKCE on federated connections. OIDC and Okta enterprise connections use PKCE, protecting the authorization-code exchange.
- Per-organization logical isolation. Each customer is provisioned as a distinct Auth0 Organization, giving logical separation of users, connections, and role assignments within the tenant (organization-scoped, not a shared global user pool).
- Least-privilege Management API access. The machine-to-machine credentials Unstract uses against the Auth0 Management API are scoped to a minimal, mostly read-only set of permissions (users, roles, organizations, and invitations) — broad or destructive scopes are not granted.
- Secrets never in source control. IdP client secrets and SAML signing certificates are supplied only as encrypted, sensitive infrastructure variables; they are never committed to any repository or stored in plaintext config.
- Bounded session lifetimes. Sessions are not persisted anywhere indefinitely. On expiry, re-authentication against your IdP is required.
- Abuse protections on non-SSO sign-in. For the username/password and passwordless connections (not used by federated Enterprise SSO, which authenticates at your IdP), brute-force protection and disposable/free-email blocking are enabled.
What Unstract persists
Unstract's application session stores only the identity attributes returned from the federated login — the user's email, a stable user identifier, and group memberships used for role assignment. It does not store your users' credentials. The documents and data you process in Unstract are never sent to Auth0 and are not part of the authentication exchange.