Token Vault — Organization Isolation

Connected Accounts scoped per org_id· the same Google/GitHub connection in one org is invisible from another

Org-Scoped Isolation

Org A

Same User

authenticated with organization=org_a

Connected Accounts

tokens scoped to org_a

Org B

Same User

authenticated with organization=org_b

Connected Accounts

tokens scoped to org_b, independent of org_a

1Tester logs in with organization=org_a — the session, and every token minted off it, carries that org_id.

2Connecting Google/GitHub here creates a Connected Account scoped to org_a's org_id. Switching to Org B does not carry it over.

3Logging in again with organization=org_b starts a separate session; the same user now sees no connection until they connect again, in that org's context.

4Disconnecting in one org only removes that org's Connected Account — the other org's token set is untouched.

What this isn't

There is no admin-provisioned, org-wide connection here — an org admin can't connect Google once and have every member inherit it. Each member still consents individually; what Organizations adds is that the resulting token set is partitioned per org_id, so the same person working across two orgs doesn't leak one org's access into the other, and connects once per org rather than needing to reconnect globally on every switch.

Auth0 docs — Token Vault, Use with Organizations.

Demo login

This demo needs a user who's already a member of both test organizations, so it isn't self-serve for a brand-new account. Sign in with the shared test account:

email: token-vault-orgs@atko.email
password: TokenVaultOrgs!2026#Qw

Security Implications

Strengths

Credential isolation is architectural, not policy-based — a Connected Account created while authenticated into one org is scoped to that org_id and is simply invisible to a session authenticated into a different org, not just hidden by an access check that could be misconfigured.
A user working across multiple organizations (e.g. a consultant on several client tenants) connects once per org rather than needing to reconnect a shared provider account globally every time they switch context.

Risks & Considerations

This is per-user consent partitioned by org, not org-wide provisioning — it is easy to overstate the feature to stakeholders as "an admin connects it once for everyone," which is not what ships. Each member still has to individually authorize the connection in each org.
org_id on the ID token is only as trustworthy as the session validation in front of it — a downstream API trusting a client-supplied org_id instead of the one on the validated session/access token reopens exactly the cross-org leakage this pattern is meant to prevent.
Same long-lived-refresh-token exposure as the plain Connected Accounts pattern, doubled: a compromised session now has standing access to whichever org-scoped connections exist for it, not just one org's worth.

Hardening Checklist

Always source org_id from the validated session/token, never from a client-supplied parameter, when deciding which org-scoped Connected Account to operate on.
Don't re-validate org membership against the Management API on every request — the signed session claim is the point; doing so just risks rate-limiting for no added assurance.
When switching org context mid-session, force a fresh login rather than assuming the SDK will silently swap organization on an already-active session cookie.