FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics
    • All categories
    • danD

      Solved What are the use cases for the user.data.email field?

      Q&A
      • • • dan
      2
      0
      Votes
      2
      Posts
      19
      Views

      danD

      It is useful in a few scenarios.

      When you have users that share an email address, but are in the same tenant and have distinct accounts. FusionAuth enforces uniqueness on user.email per-tenant. When your users have a username (such as an account number) as a main unique identifier, but need self-service account recovery. When you have duplicate email addresses in a legacy system and are migrating them to FusionAuth, whether they point to the same account or not. You can move the users over and address email updates or account merges later.

      Not all email related functionality is available when using user.data.email, but common workflows like forgot password are.

    • danD

      Solved What are FusionAuth entities good for?

      Q&A
      • entities • • dan
      2
      0
      Votes
      2
      Posts
      25
      Views

      danD

      Entities are one of the most flexible parts of FusionAuth and can be used to represent links and/or permissions between domain objects and users.

      Entity types are like classes in an object-oriented programming language, which define the permissions that an entity can have.

      Entities are similar to objects, in that they are an instantiation of an entity type. No behavior though, and no inheritance.

      Entities are connected to users and other entities via grants. You can think of this setting up a directed permission graph that can be traced.

      0 to N permissions are attached to each grant.

      There are three major uses for entities:

      the client credentials grant (agentic, machine to machine or service account authentication) building limited fine grain authentication (FGA-ish) systems that don't need full ReBAC, but do want to use a permission graph or dynamically add and remove permissions modelling permissions on something you don't log into

      A few notes about entities:

      you'll want to get familiar with the API or the client libraries; entities are managed in code. Both in creating the graph and reading it from your application. each entity has a data field which can handle arbitrary JSON and is searchable the graph can be cyclic if you make bidirectional grants between entities. Users cannot accept grants, they can only be granted permissions to entities. if you need full ReBAC or ABAC, you want FusionAuth FGA. More functionality, including automatic relationship graph traversal. The downside is you have to sync data and run a separate service.