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.

I see the user.data.email field is used when it is present and user.email is not present. From the doc:

This field will be used as the email address if no user.email field is found. This field may be modified by advanced registration forms or the API. Setting this value to another account's email address allows that account to, in some cases, access information about this user.

What are the use cases for that field?

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.

I'm curious about entities. What are they good for?

As of 1.69.0, you can now update the password hash using the User API.

From the documentation, the passwordFieldType is the API field to use. This field:

Describes what user.password in the request is. The possible values are:

HASHED - user.password is an already hashed value. When this value is supplied, user.encryptionScheme, user.factor, user.password, and user.salt are required.
PLAINTEXT - user.password is a plain text/unhashed value. FusionAuth will hash this value according to user.encryptionScheme and user.factor.

@njanaskie I don't have any experience with that flow. Hopefully someone that may have had some experience with this can chime in.

@njanaskie said in Update on supporting discoverable WebAuthn credentials:

You are right. FusionAuth does not support discoverable WebAuthn passkeys. In the page you referred to, there is some verbiage that states that directly in the credential.clientExtensionResults.credProps.rk section.

'FusionAuth does not currently support discoverable credentials (sometimes referred to as "resident keys").'

I'd recommend checking the FusionAuth GitHub issues or opening/upvoting a feature request to track progress on this.

Maybe if you tell us a little more about your use case and why the user can't enter the username/email someone can help with a work around.

You want to modify the Two-Factor Login duration in the Tenant Settings, which applies across to SMS and MFA methods.

https://fusionauth.io/docs/get-started/core-concepts/tenants#advanced has more details.

Users who's email is lagged by 30 - 60 seconds , the emailed MFA verification code has expired by the time they receive them. I've done a Zoom meeting with the user and verified they are doing everything correctly, but their email is web mail based and must be from cloud provider that has a really slow system. They probably get the email about 60 seconds of they click send verification code and it always fails to verify.

I can't find anything in settings to change the timeout or searching the documentation. Is there a setting for this somewhere that I could change or could Emailed Verification codes be good for at least 90 seconds?

ported to forum from https://github.com/FusionAuth/fusionauth-issues/issues/3545

Hi folks,

We recently enabled Intelligent MFA for the forum application.

If you don't have MFA set up, you'll be prompted to enable it.

Then, going forward, you'll be prompted for MFA if and only if the authentication is determined to be high risk.

Please contact us if you have feedback.