I can't speak to FusionAuth in particular, but when you have a public client you ideally don't want to use the client secret for anything, since SPAs / Mobile Apps / etc cannot keep a secret.

Edit: Found this Github issue marked as wontfix: https://github.com/FusionAuth/fusionauth-issues/issues/2173

If you do need a confidential client for something you should have a separate client for it.

So, my take would be that since you shouldn't be using that secret for anything you shouldn't need it to be required for any flow.

You also didn't ask this but you do want to have PKCE enabled for your SPA's client.

@kasir-barati Hiya, welcome to FusionAuth. Sorry, just ran across your forum post today.

There is no way to assign constraints to user.data fields within FusionAuth, but there is an open issue that I encourage you to upvote.

You can require usernames to be unique in a tenant, using the Unique usernames setting. It is, however a feature which requires a paid plan.

Another alternative, rather than

fetching all users and then looping over users
would be to search for the username before creating the user. Using the search functionality that wouldn't require scanning all the users. You can use a transactional webhook to fail user creation if your uniqueness rules are not met.

This is due to a bug in the openjdk java library that the docker image uses. You can learn more about the bug here and track our fix (which looks like upgrading the java image our docker file users) by following this bug.

Until then, the workaround is to pass this java argument at start time:

-XX:UseSVE=0

This argument disables the use of the SVE extension, which is provides "better data parallelism for HPC and ML".

You can do that with the FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS environment variable in your Dockerfile. Here's an example:

fusionauth: # ... environment: # ... FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS: -XX:UseSVE=0

Thanks for your answer. I got it.

MAU Billing in Non-Production Environments:
Authentication activity in your non-production environments will not count toward your MAU billing as long as you are not using the "production" license key on those instances. How to Ensure Testing Does Not Impact MAU Totals: Use separate non-production license keys for your testing environments. Ensure these keys are applied to your non-production instances, isolating them from your production MAU calculations.

For more information, refer to the following resources:

FusionAuth Licensing Documentation What Makes a User Active?

This setup allows you to run comprehensive automated tests in your non-production environments without affecting your billing.

Bulk Registration of Existing Users:
FusionAuth does not currently provide a bulk endpoint for creating user registrations. However, you can achieve this by using the Create User Registration API to programmatically register users to app2. This requires iterating through the list of existing users and making an API call for each user to add the new registration. Best Practices for Future Scenarios:
To avoid manual one-time activities like this in the future, consider the following approaches: Enable Self-Service Registration:
If you are using FusionAuth's hosted login pages for user sign-ins, you can enable self-service registration for app2. With this feature, a user will automatically have a registration created for app2 when they attempt to log in for the first time. Programmatic Registration:
Implement a workflow in your onboarding process that ensures users are automatically registered to all relevant applications when they are created or updated in your system. Custom Scripts for Batch Processing:
Write a script to fetch all existing users and register them to any new applications as needed. This can be reused whenever new applications are added to your system.

References:

Create User Registration API Self-Service Registration

These steps should help streamline your workflow and reduce manual intervention for future scenarios.

There seems to be a misunderstanding regarding the deprecation timeline. The /api/user endpoint itself is not being deprecated at the end of the year; only JWT authentication for that API is being deprecated. You can continue to use the /api/user endpoint by switching to API key-based authentication.

Steps to Continue Using /api/user:

Update your integration to authenticate API calls with an API key instead of JWT. Access data.salutation as usual through the /api/user endpoint. This data is part of the user.data object, which is populated by your integration and not automatically generated by FusionAuth.

Steps to Use /oauth2/userinfo:

Write and install a UserInfo lambda which can read the user.data object and augment the userinfo response to include the data.salutation value. Docs on this lambda.

Unfortunately, FusionAuth does not currently support using AWS IAM authentication for database connections or automatic rotation of database credentials. There is an open issue tracking this feature request:
GitHub Issue #973.

For now, this functionality would need to be handled outside of FusionAuth. For example, an external process or tool could be used to manage the generation and rotation of AWS IAM tokens. This might involve periodically restarting FusionAuth on a rolling 10-minute basis to ensure it picks up the updated credentials, or implementing a custom solution that works in conjunction with FusionAuth to manage database authentication. However, such approaches would not be officially supported by FusionAuth.

The POST /api/user/change-password endpoint does not support a flag to require a password reset. However, you can achieve this by using the PATCH /api/user/{userId} endpoint and setting the passwordChangeRequired field in the request body.

Here’s an example JSON for the PATCH /api/user/{userId} call:

{ "user": { "passwordChangeRequired": true } }

Alternatively, you can set this requirement manually via the FusionAuth Admin UI:

Navigate to Users > Manage User > Edit User Dropdown. Select Require Password Change.

Documentation for reference:

Update a User

This ensures the user will be prompted to reset their password upon their next login.

You can retrieve this data using FusionAuth's API, which provides specific endpoints for users, entities, and entity grants. The users object includes a registrations section that lists the applications each user is registered with. Here are the relevant API endpoints and documentation:

Users: Search for Users Entities: Search for Entities Entity Grants: Search for Grants

Steps to Retrieve Data:

To fetch all users, entities, or grants, perform a search query with a queryString parameter set to *. Use pagination as described in the API documentation to handle large datasets efficiently.

This approach allows you to systematically acquire the information your data engineers need on a daily basis.

FusionAuth does not have a cascading Identity Provider (IdP) feature like Keycloak. Once an IdP is enabled for a FusionAuth application, it is available to all users logging into that application, and all enabled IdPs appear on the application’s login page, unless you modify the theme to change default behavior.

However, FusionAuth offers a feature somewhat similar to cascading IdPs: Managed Domains for Identity Providers. Here’s how it works:

On the login page, users are initially prompted to enter their email address. Based on the email domain, FusionAuth automatically redirects the user to a specific IdP or to the standard username/password login. For example, users with @company.com could be directed to a corporate SAML IdP for authentication, while other domains can be mapped to different IdPs or the default login flow.

Key Differences:

Predefined associations: You must configure email domains to map to specific IdPs beforehand. No chaining logic: FusionAuth does not attempt multiple IdPs sequentially during a single login attempt.

While Managed Domains is not equivalent to cascading IdPs, it is the closest feature FusionAuth provides for streamlining authentication based on user characteristics.

There are a few approaches and tools you can consider to streamline this migration process:

Database Migration Tools:
Tools like pgloader can help automate the migration of your MySQL database to PostgreSQL. Be aware that direct database migration carries risks. Corrupt or incomplete data may not surface immediately, and issues could arise months later. To mitigate this, test the migration extensively and consider working with third-party experts if needed. API-Driven Migration:
While using API calls for migration can be time-consuming, it ensures the data integrity FusionAuth requires. Automating this process with scripts and batching requests may help speed up the operation. Terraform for Configuration Migration:
Terraform can simplify the configuration migration process by treating your infrastructure as code. This approach allows you to standardize and automate the setup of configurations in your new FusionAuth Cloud environment. It’s especially useful for managing tenants, applications, and other configurations consistently.

Important Note:
If you choose to use a database migration tool, proceed with caution:

Verify the migrated data thoroughly to ensure it matches FusionAuth’s schema and expectations. FusionAuth cannot provide support for issues caused by manual database manipulation or corruption.

Combining API-driven data migration for sensitive information with Terraform for configuration and a reliable database migration tool can significantly reduce the time and effort required for this migration.

Managed Domains Configuration:
If the client’s users share a common email domain (e.g., @example.com), you can use Managed Domains to streamline their login process. Here’s how it works: On the login page, users are first prompted to enter their email address. If the email domain matches a Managed Domain defined in the Identity Provider settings, the user is automatically redirected to Azure for authentication. If the email domain does not match, the user proceeds to the standard email/password login flow. For example, you could configure it so that users with @company.com emails are redirected to a corporate SAML Identity Provider, while your Azure users are handled similarly.
This approach changes the login page for all users by requiring them to enter their email first. For more details, refer to the Managed Domains documentation. IdP Hint with a Custom URL:
Another option is to use an Identity Provider (IdP) hint to create a unique login URL specifically for this client. Users accessing this custom URL are redirected directly to the Azure login page, bypassing the normal login flow. If the client uses the standard login link, they will still see the regular login page. This method ensures a tailored experience for the client without affecting other users. More details can be found in the IdP hints documentation.

Both approaches are effective, and the choice depends on your use case. Managed Domains is ideal for a seamless experience across shared email domains, while the custom URL approach offers greater separation for specific clients.

Having contemplated raising a bug for this issue, I've discovered that it, or something very similar, is in fact already the subject of a GitHub Issue. The issue was raised out of this Forum Thread, which provides some avenues for further investigation. Thanks for the responses @mark-robustelli & @kvi68507

@Scot Woo-hoo, glad you got rollin'!

I think you should implement custom registration or login logic using FusionAuth's webhooks or API. For example, you can check the application context during login and prevent users from being registered or authenticated in an application they are not supposed to access.

You should ensure that the redirect URI you are using is correctly configured in your application settings on Aithor. It should match the expected URI exactly.

@cluong Hmm, Just to verify, when you submit the data, do you get a URL that looks similar to this?
https://sptest.iamshowcase.com/ixs?idp=581409a977a79eb0f979f2f591204c8f69f0f334

It does not surprise me that the WebAuthN Wizard would fail if we cannot get the url provided to work.

For clarification, it is my understanding that iamshowcase is the SP in this test case and FusionAuth is the IDP. I never used the "Initiate login URL" when setting up the SP initiated SSO.

For the record, if I enable "Enable IdP initiated login" from the SAML tab of the Application, I too am able to see the federated page.
When setting up the SP initiated SSO, I do not use the url provided by "Initiate login URL."

Would you be able to share the Metadata URL or the xml that it produces? Could you also share a copy of your Application -> SAML tab configuration. (feel free to mark it up and hide any information you do not want public.) If that does not work for you, I suggest setting up a test instance so you can share some more detail so we can get this working for you. Also, what version of FusionAuth are you working with?

@tschlegel Thanks for sharing the update!