Skip to main content
Use this when each external customer maps to its own enterprise connection (a SAML or OIDC connection to their IdP, for example) instead of an Auth0 Organization. A user’s tenant membership follows which connection they authenticated through, and which groups their IdP put them in via SCIM. This is an alternative to B2B via Organizations: no Auth0 Organization is involved anywhere in this model. A connection is the organization boundary here: a user reaches it either directly, or through a SCIM group that belongs to it.

Model

Mapping

connection#member accepting group#member (alongside user) is what lets a user reach the connection either directly or through a SCIM group, with the same relation either way. “Link group to connection on creation” writes both the bookkeeping group --connection--> connection tuple (which connection owns this group) and the group#member --member--> connection tuple that actually grants every group member connection membership. With that in place, a Check for user#member@connection resolves true for a user added directly and for a user added to any group on that connection, and false for a user who was never added to either.
Auth0’s event schema for user.created and user.updated only requires context.tenant, so context.connection is optional and can be absent. Don’t rely on it to identify the connection. Read data.object.identities[].connection instead, which the schema always includes; it holds the connection’s name, not its ID, and is paired with that identity’s user_id.

Known limitations

  • Connection deletion isn’t handled above. connection.deleted exists as an event, but this mapping doesn’t clean up a user’s direct connection membership or a group’s connection tuple on deletion; add a tuple_filters rule modeled on “Revoke all group tuples on deletion” if you need this.
  • Roles. There’s no per-user role assignment tied to a plain connection. If you need roles here, assign them to the SCIM group itself; see Roles: a group, at the tenant level.