FusionAuth's logging isn't one system, it's three: system/app logs on disk or stdout (monitor docs, troubleshooting), audit logs for admin UI changes via webhooks or the Audit Log API, and event logs for debugging surfaced through webhooks or the Event Log API.

None of them ship anywhere on their own, so if you want this in Datadog or Splunk, you're polling the API or writing your own ingester (by following doc, but still).

We're looking for feedback on this.

What's great about FusionAuth's logging, and what sucks or needs to be improved?

@anarelynevarez, Thanks for looking us up. While Buckeye Union High School District may use FusionAuth, they own the implementation of FusionAuth. You will have to reach out to them for this kind of assistance.

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.