Tenants

• Use separate tenants when you need complete isolation between environments (e.g., different customers in a multi-tenant SaaS product, or separate production/staging environments with distinct user bases)
• Use a single tenant when your users and applications share the same authentication realm
• Tenants provide the highest level of separation — each has its own users, applications, groups, and configuration

Entities and Entity Types

• Entity Types define categories of non-user objects in your system (e.g., "Device", "API Client", "Organization", "Service Account")
• Entities are instances of those types (e.g., a specific device, a specific organization)
• Use entities to represent OAuth2 concepts like:
  • Client credentials for machine-to-machine authentication
  • Devices in device authorization flows
  • Organizations or business units that own applications
  • Non-human actors that need permissions or relationships to users

Common Pattern

A typical OAuth2 architecture in FusionAuth might look like:

• Tenant = Your authentication realm/environment
• Applications = Your OAuth2 clients (registered apps that can authenticate users)
• Entity Types = Categories like "Organization", "Device", or "API Client"
• Entities = Specific instances (e.g., "Acme Corp" as an Organization entity)
• Users = End users who authenticate

The key is mapping your OAuth2 concepts to FusionAuth's primitives based on whether they represent users (User objects), applications (Application objects), or other non-user actors/resources (Entities).