Good question. I believe this is due to how we implemented our PATCH calls. If you are making a straight API call, you can change the Content-Type header to application/merge-patch+json which will instead overwrite the existing array with whatever you have provided. That's the most straightforward way to replace array values. There are other methods detailed in the doc below but those involve removing values one by one instead of just overwriting them. The downside here is that I don't believe Client Libraries usually support the merge-patch header.

https://fusionauth.io/docs/apis/#the-patch-http-method

If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

The transient policy is not something FusionAuth will support for the SAML NameID policy. From the SAML standards doc, a transient NameID is supposed to be a temporary value which is not a good basis to build a link between two identity systems on. That is the main reason FusionAuth does not support this policy as it would likely lead to issues later down the line with the Identity Provider. Apologies for the inconvenience but having the User ID/UUID shift or change would cause problems as FA relies on a consistent User ID/UUID(NameID) to make a SAML link work.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Currently, there is not a way to turn it off. Our air gapped license is still going to try to make that call out to us, but that won't cause any issues. The difference being that a normal license would have issues if it could not "phone home" back to us whereas the air gapped license won't have issues but it will still try to make those calls.

If you want to change the font on the hosted login page and the login experience users are offered through FusionAuth, then this can be changed via our Themes. Very likely you will want to update the CSS associated with the theme you are using for the FusionAuth Application/Tenant. Changes to the theme can be completed through this API: https://fusionauth.io/docs/apis/themes/advanced-themes.

Alternatively, you can use the Admin UI to make changes to your CSS as well.

Yes with a Basic Cloud you get one custom domain and no backups, you would just need to update your DNS records to include our CNAMEs for this custom domain. You would submit your custom domain via the Hosting tab of the account.fusionauth.io under the Action Drop down. Then you will be shown the CNAME record for that domain and you will have to update your DNS records to include this CNAME. You can see an example of this at the doc below.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#custom-domains

You would not be able to use your own SSL certificates. We would handle all those in FusionAuth Cloud. We create the certificates on our end and you just need to create DNS records to validate the domain with the CNAME records.

Thanks for the question. Updating your instance wouldn't change your situation. Currently, the only options are what you found outlined in the documentation you mentioned.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#captcha-and-rate-limits

As we build out our Cloud Offerings there may be other options, but this is what is currently available. Oftentimes, we find that people will use a local copy of FusionAuth to complete their automated testing if they cannot locate an IP address that meets our allowlisting requirements.

There are a few ways you can get what you need. You can either make these changes via the API and then they will be updated in the UI.

https://fusionauth.io/docs/get-started/core-concepts/users#user-data

https://fusionauth.io/docs/apis/users#update-a-user

Or you can do this using custom admin forms:

https://fusionauth.io/docs/lifecycle/manage-users/admin-forms

The license ID is just the license key itself. You can grab your license here https://account.fusionauth.io/account/plan/. Each license will have a prod key and non-prod key, for testing you just need to grab the non-prod key and use that for your license ID in Kickstart.

https://fusionauth.io/docs/get-started/download-and-install/development/kickstart#set-your-license-id

If you are using the React SDK (which uses Hosted Backend: https://fusionauth.io/docs/apis/hosted-backend, then there are a couple options but they will all require some integration work from your end. The SDKs and Hosted Backend are designed to be easy to use and implement but they are not flexible as you can see with the cookies. Also I'm not sure if this was a consideration in the decision that running FusionAuth locally is not an option but just in case it was: You can use your FusionAuth non-production licenses wherever you want, we do not charge more "per deployment". So you can activate your non-prod license on a locally hosted FusionAuth instance in addition to your FusionAuth on Azure App Service, you can run your non-prod license on as many instances as you want.

Develop your application while hosting it on Azure App service so FusionAuth and the app are on the same domain

Setup a proxy for either your application or FusionAuth so they can be on the same domain

Documentation for setting up a proxy for FusionAuth: https://fusionauth.io/docs/operate/deploy/proxy-setup

Create your own Hosted Backend, example here: https://github.com/FusionAuth/fusionauth-javascript-sdk-express/tree/main

Similar to #3, instead of setting up a Hosted Backend use the OAuth2 endpoints directly. In this scenario you will also be responsible for doing the OAuth code exchange for a token then setting the token cookies on the browser as well as session management with these tokens.

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints

https://fusionauth.io/docs/operate/secure/token-storage

Currently your deployments do support custom domains and yes this would be compatible with PKCE. You can have something like auth.mycompany.com provisioned and a user can bookmark this type of URL. In fact, I believe that your company already has a few of these types of URLs configured. So your customers would have to bookmark the full login path (something like http://auth.mycompany.com...authorize?client_id....redirect_uir...response_mode) and then they can login to the OAuth2 page that FusionAuth is hosting for login.

The real issue that you have here is related to PKCE.

Your app landing page is generating a PKCE challenge and PKCE verifier.

Your integration is then using these values to call the authorize endpoint uniquely each time

If a user bookmarks the values/URLs from step two above, they will have issues logging in (due to a PKCE failure)

All of this is in alignment with the OAuth Specification (the PKCE values should be unique each time that the authorize endpoint is called). The next question then becomes prevention of a user bookmarking the wrong link. To my mind, you could add some information to a customer portal or land page letting the customer know the correct page to bookmark. If the login fails, you may be able to redirect the user to the correct page (your page sees the failure and then determines the login landing page to send the user to) to login as well to recover the customer experience (in the case where the user have bookmarked the wrong link).

The alternative is to not to use PKCE, which introduces security considerations, especially if you are building on mobile.

Yes, you would need something on your end to poll the Audit Log to fetch changes made to the Entities. Currently. there's no way to enter a log into the system logs (fusionauth-app.log) or otherwise control what goes in there. We do have a similar example for Cloudwatch on exporting Login Records to Cloudwatch which should be helpful.

https://fusionauth.io/docs/operate/monitor/cloudwatch

Having only one user be able to log in with username/password is relatively straightforward with FusionAuth. You could use a Login Validation Lambda or transactional user.login.success Webhook to check the authentication type on each login, which will tell you if they are logging in via a specific Identity Provider or with a password then stop users from logging in based on that criteria. Then set it up so that only the break glass user is able to login with a password.

The slightly trickier part here is only having the username/password field show up for that user. The only way to accomplish this with Simple Themes would be to have managed domains setup such that all normal users are directed to IdPs but the break glass user is on a separate domain so they get to see the login page. With managed domains, the login field changes just to email address for the first step. Then it will check the users email address against domains you have setup for specific IdPs and if they match a IdP then a user is directed straight to that IdP. Any user with a domain that does not match gets sent to the regular email/password login page.

https://fusionauth.io/docs/extend/code/lambdas/login-validation

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success

https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/#managed-domains

This is a little tricky since a user could log in from either provider at any given time. The JWT populate lambda only has access to the user object and the registration object so you would need something on either of those to reference in the lambda. Each time a user logs in from a Identity Provider, the user in FusionAuth gets updated with the user data from the IdP. So for the JWT populate to work, you would need both providers to have a custom data field that maps to the same user.data field in FusionAuth. Then have the JWT populate Lambda map this user.data to either a custom claim or to the roles claim in the JWT, whatever works to determine the internal role on your side. Essentially this field would get updated or overwritten every time the user logs in and which would means the JWT from that login should have the correct "role".

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate

A JWT populate lambda runs whenever a JWT is minted and the reconcile lambda runs whenever a user logs in from an IdP. Which means there is a scenario if a user is logged in on both networks at the same time, it would not be accurate since the JWT from both sessions would be reading from user.data which got updated by the last IdP login. Something like the following feature would also likely be enough to solve this problem for you, we have a similar field on Webhooks but not in JWTs or Lambdas which would detail which IdP used to login.

https://github.com/FusionAuth/fusionauth-issues/issues/1483

It makes sense that this problem is happening. Once we have a SSO session on the computer/browser, then if MFA is required as part of the hosted workflows, FusionAuth will prompt for it based on the existing SSO session.

To solve this problem, you could opt to not make use of the FusionAuth SSO session. So, if you are using our Advanced themes, you could remove the option for an SSO session by removing the Keep Me Signed In checkbox from the theme. Using our Simple Themes, you would set the SSO Session to a really short duration in Tenant Settings (2 seconds, for instance) thus effectively removing the SSO session. Both of these options would eliminate this problem described above.

If you still wanted to generate a FusionAuth SSO session, and you wanted to solve this specific problem, you could use Advanced Themes and hardcode a logout link on this MFA page to allow a user to reset the session and login again. This same solution is not possible using Simple Themes, but a feature request could be logged if you wanted to see this logout link included in Simple Themes at a later date.

To upgrade the FusionAuth deployment, you just need to visit account.fusionauth.io and go to the Hosting tab. From there, each deployment has a drop down button where you can select Upgrade. From there you can upgrade version by version or leapfrog to the latest version, we always recommend testing out the upgrade on dev before rolling it out to production. For your dev instances, there will be downtime of up to 60 minutes but usually I see it takes 20-30 minutes. For production we do a rolling node upgrade since it's a multi-node instance, therefore it should not have much downtime at all(seconds) as traffic just gets routed to nodes 2 & 3 while node 1 is getting upgraded.

As far as rollbacks and backups, we keep snapshots of the database for your production deployment since its High Availability. Your dev and staging instances do not have backups since they are Basic Cloud. If you want to enable backups and rollbacks, you would need to move the Dev or Staging instance to the next tier of hosting, Business Cloud. For production, we will take a snapshot of the database every time right before you upgrade. These backups are available for up to 30 days. Then we also have 3 days of general rolling backups for your production that we can rollback to. Rolling back is a manual process from our end so that's something you have to contact us to initiate. Something to keep in mind is that it's a complete database rollback, so any logging or changes made since the snapshot will be lost so there is data loss with these rollbacks.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#upgrading-a-deployment

With the Essentials plan, you do have MFA available to you on a Tenant level under Tenant>Multi-Factor. To have users set up MFA you either need to set MFA to Required, where users will need to set up MFA to complete a login or you will need to enable the “Self Service Account Management” page so users can visit it to set up MFA. So you can set up MFA for any Tenant to make it available to users.

https://fusionauth.io/docs/lifecycle/authenticate-users/multi-factor-authentication

https://fusionauth.io/docs/lifecycle/manage-users/account-management/

In order to change MFA settings at the Application level for enabling MFA on a project by project basis, you would need to upgrade to the Enterprise plan.

Thanks for the question! If you navigate to Applications > Index View - FusionAuth > Multi-Factor Tab then you can see an option to require MFA for the FusionAuth Admin UI Application. You will likely want to enable application specific trust as well.

Currently, FusionAuth lambdas cannot call the API without including an API key in the code — there’s no built-in secret manager for this yet (feature request).

Alternative approaches:

Webhook filtering (recommended)
Use the user.login.success webhook to check if the user is linked to an IdP, and reject the login by returning a non-200 response. This avoids storing API keys in lambdas, but adds an extra network call to each login.

Store link data in user.data
Push IdP linking info into a custom user.data.links[] field so it’s accessible in most lambdas without needing an API call. You’ll need a process to keep this data current.

You can remove claims from the SAML response using a SAML v2 populate lambda. For example:

samlResponse.assertion.attributes['firstName'] = null; samlResponse.assertion.attributes['lastName'] = null;

Attach this lambda to your SAML Identity Provider configuration for that application.

Documentation: SAMLv2 Response Populate Lambda