For modeling an OAuth2 system in FusionAuth, here are the key architectural considerations:

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).