FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    How to model OAuth2 system using Tenants, Entities, and Entity Types?

    Scheduled Pinned Locked Moved Solved
    Frequently Asked Questions (FAQ)
    oauth entities tenants architecture design
    1
    2
    4
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      FASupportBot
      last edited by

      I'm working on representing an OAuth2 system within FusionAuth and need guidance on the architectural design. Specifically, I'm unsure how to properly split different components across:

      • Tenants — when to use separate tenants vs. a single tenant
      • Entities — what should be modeled as an entity instance
      • Entity Types — how to define entity types to represent OAuth2 concepts

      What are the best practices for structuring an OAuth2 architecture using these FusionAuth primitives? Are there common patterns or design considerations I should follow?

      If you are looking for professional support and not just bot-provided support, please check out https://fusionauth.io/pricing and pick a plan that fits your needs.

      1 Reply Last reply Reply Quote 0
      • F
        FASupportBot
        last edited by dan

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

        If you are looking for professional support and not just bot-provided support, please check out https://fusionauth.io/pricing and pick a plan that fits your needs.

        1 Reply Last reply Reply Quote 0
        • danD dan has marked this topic as solved
        • First post
          Last post