@pc Was anything changed before the reboot? What prompted the reboot?

@theogravity-sb Hmmm. So the issue is that someone is registering with a gmail account they control but it looks like this:

foo@gmail.com with a name of <Dan https://evil.com> which is being turned into a link?

Or am I misunderstanding your question?

JWTs Cannot Be Revoked: Once a JWT is issued, it remains valid until it expires. JWTs are decoupled authentication tokens, meaning they do not require continuous validation against a central authority. While OAuth2 includes a token introspection endpoint, it is only useful for access tokens and does not support JWT revocation. What the /oauth2/introspect Endpoint Does: This endpoint verifies whether an access token is valid based on its signature, expiration time, and format. It does not check whether a user’s account has been locked or disabled. Impact of a Locked Account on JWTs: If a user’s account is locked, they will not be able to obtain a new access token. However, any previously issued JWTs will continue to be valid until they expire, unless you implement additional measures. How to Handle JWT Revocation:
Since OAuth2 does not include JWT revocation natively, you can implement one of the following approaches: Use Short Token Lifetimes: Issue JWTs with short expiration times and rely on refresh tokens for continued access. Leverage Webhooks for Denylisting: Use FusionAuth’s event system to notify services when a user is locked or a token should no longer be valid. Services can then maintain a blacklist of invalidated JWTs.

For more details, refer to:

Revoking JWTs in FusionAuth

Yes, exchanging a refresh token for a new access token (JWT) does count as a login event in the Login report.

Events That Count as a "Login":

A login is completed using any Login API (e.g., normal login, one-time login, passwordless login, Identity Provider login, or Connector-based login). A user is created with a password (whether through self-service registration or the Registration API). A refresh token is exchanged for a new JWT. A user successfully completes a 2FA login.

For more details, refer to:
What Makes a User Active?

The initial API key created during setup is primarily intended for administrative use and API access. While it is not directly used within the FusionAuth UI, it can be used to authenticate API requests depending on the permissions granted to it.

Recommendations:

Keep an API Key for Emergency Access: It is advisable to retain at least one API key for break glass reasons—for example, to regain access in case of authentication issues. API Usage: API keys are commonly used to interact with FusionAuth’s REST APIs for various authentication and management tasks.

What Happens If You Delete It?

If no other API keys exist with sufficient permissions, API-based administrative access to FusionAuth will become unavailable. If your system relies on this API key for integrations or automation, those requests will fail.

To avoid disruptions, ensure that you have another valid API key with the necessary permissions before deleting the initial one.

@cristian I asked around a bit, and unfortunately I don't have a great answer for you. I think this information about FusionAuth SSO just confirms what you already know.

On a slightly brighter note, someone helped me find this open GH Issue that you should probably follow that might help down the road.

In the meantime, does anyone have any other advice or suggestions for @cristian?

I just took another look and jwt.aud may get you what you need in both instances as well.

@megharaj-khalate Can you please provide a little more detail in how you are adding users to FusionAuth? Have you checked the FusionAuth logs to see if there are any clues there?

@bonfattidaniele Is auth.easycbam.eu your domain? Is bbdb8f55-65e7-4de7-a5ff-f08df4ea8005 your client_id? Is 9f144ac0-3006-e653-2ce1-ba98bb40f3eb your tenantId? It appears that those values may not have been updated if not. I am not an Apache expert so I am not sure what implications removing those statements is going to have. Can you try updating those ids, domains and other variables in the config to see if that works?

@spydmobile Are all the errors specifically about the CORSConfigurationCacheLoader or are there others?

@spydmobile said in Struggling to backup selfhosted fusionAuth.:

2025-01-31 16:33:45 fusionauth-1 | 2025-01-31 11:33:45.952 PM ERROR com.inversoft.scheduler.LogAndRetainFailureHandler - The scheduled service [class io.fusionauth.api.service.cache.CORSConfigurationCacheLoader] failed but will be re-run.
2025-01-31 16:33:45 fusionauth-1 | org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or null) to be returned by selectOne(), but found: 2

Yes, it is possible to configure a custom domain for your SAML audience URL using FusionAuth's Custom Domain feature. This setup allows you to map your desired domain, e.g., https://auth.company.com, to your FusionAuth instance, enabling the SAML audience URL to use your custom domain.

Steps to Achieve This:

Set Up a Custom Domain: Configure a custom domain in FusionAuth (available for production deployments). Once the custom domain is set up, the SAML audience URL will change to reflect your domain, e.g., https://auth.company.com/samlv2/sp/<id>. Update DNS Records: Point the custom domain (auth.company.com) to FusionAuth Cloud using the provided instructions during setup. Verify SAML Configuration: Ensure the custom domain is reflected in the audience URL and SAML metadata. Update your SAML federation partners with the new audience URL.

Additional Notes:

Issuer Setting: The "Issuer" setting on the tenant configuration only affects JWTs and is unrelated to SAML audience URLs. Custom URL Limitation: You’re correct that the login.fusionauth.io option allows for aliases to the default company.fusionauth.io domain but does not impact SAML audience URLs. Setting up a full custom domain resolves this limitation.

Yes, it is possible to configure an Application with the SAML IdP feature enabled and use it as an IdP for another Application within the same Tenant.

The error you’re encountering indicates that FusionAuth cannot find an Application configured as a SAML IdP with the Issuer URL https://company-stage.fusionauth.io/samlv2/sp/af59262c-79ba-48c6-a0a2-4ab1d2fc15d3. This URL corresponds to the Identity Provider you configured in Settings > Identity Provider.

Resolution:

To fix this issue, update the SAML configuration for Application B as follows:

Navigate to Application B > Edit > SAML. Add the Issuer URL (https://company-stage.fusionauth.io/samlv2/sp/af59262c-79ba-48c6-a0a2-4ab1d2fc15d3) in the Issuer field.

By doing this, FusionAuth will recognize the SAML request and correctly map it to Application B.

The behavior you are experiencing is working as designed.

Currently, only the global_admin role can bypass the OTP requirement to disable 2FA. While the user_support_manager role allows managing other user account aspects, it does not have the necessary permissions to bypass 2FA for removal.

Feature Request Option:
If this functionality is critical for your workflow, you could consider submitting a feature request to extend this capability to additional roles in a future release. Or review this issue and comment if it meets your needs.

@stefan-0 I don't really see where there is an issue here, we wouldn't want to actually keep the Azure AD access_token if you want it just add something to the openid reconcile lambda and store it as needed.

https://fusionauth.io/docs/extend/code/lambdas/openid-connect-response-reconcile

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.