Existing Role Limitations in FusionAuth FusionAuth provides predefined Admin UI roles, which are not modifiable. You can review the available roles here:
FusionAuth Admin UI Roles The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available. Requesting Read-Only Roles as a Feature FusionAuth does not currently support read-only access roles for applications or tenants. The likely reason for this is that users who need to view application/tenant properties often also need to update them. However, you can submit a feature request to suggest adding read-only roles:
Submit a Feature Request Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data. Relevant APIs for this purpose: Application API Tenant API

Summary

No built-in read-only roles exist for applications or tenants. FusionAuth Admin UI roles are not modifiable. You can request read-only roles as a feature via GitHub. A workaround is to build a custom, API-based read-only view.

This behavior is a result of session management at the identity provider level (Azure AD), not FusionAuth. When federating authentication to an external IdP, FusionAuth does not control how sessions are managed within that IdP—Azure AD determines session persistence and re-authentication policies.

Why This Happens:

When UserA logs out of your application, their Azure AD session remains active unless explicitly ended. When UserB attempts to log in, Azure AD automatically reuses the existing session (UserA’s session) instead of prompting for new credentials. Since FusionAuth relies on the identity assertion from Azure AD, it issues a token based on the session provided by Azure AD, resulting in UserA’s credentials being used.

How to Prevent This:

1. Ensure Proper Logout from Azure AD

When logging out a user, also log them out from Azure AD to end their IdP session. This is typically done by redirecting the user to Azure AD’s logout URL during the sign-out process.

Example for Microsoft Entra ID (formerly Azure AD):

https://login.microsoftonline.com/common/oauth2/logout?post_logout_redirect_uri={your-app-logout-url} This ensures that UserA is fully logged out before a new user attempts to sign in.

2. Disable "Keep Me Signed In"

Many IdPs, including Azure AD, offer a "Keep me signed in" option. If the machine is shared, instruct users not to enable this option, as it maintains the session even after closing the browser.

3. Enforce Re-authentication

Some IdPs provide settings to force authentication on each login attempt.
*In Azure AD, you can modify your SSO session policies to require fresh authentication after logout or in specific conditions (e.g., IP changes, new browser sessions).

If your application requires frequent user switching, consider enforcing authentication via the prompt=login parameter in the Azure AD authentication request:

https://login.microsoftonline.com/{tenant_id}/oauth2/authorize?prompt=login

Summary

FusionAuth trusts the session response from Azure AD, so this issue must be resolved at the IdP level. Logout must also happen at Azure AD, not just your application. Session settings in Azure AD should be configured to ensure proper user switching. For shared devices, instruct users not to use "Keep me signed in."

For more details, refer to Azure AD’s session management documentation or configure logout redirects properly within your FusionAuth setup.

Yes, FusionAuth provides this information via the authenticationType claim in the JWT. This claim indicates the authentication method used, such as PASSWORD, GOOGLE, SAML, etc.

How to Access Authentication Type:

From the JWT: The authenticationType claim is included in the JWT access token. Documentation: JWT Access Token Claims From a Webhook Event (Alternative Approach): The same authenticationType value is included in the user.login.success webhook event. This may be useful if your system processes authentication events via webhooks instead of decoding JWTs. Documentation: User Login Success Webhook

For additional details on JWT structure and claims, refer to: JWT Components Explained

This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.

This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.

So, two options:

upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work. as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

@davidhaven1246 Have you checked out the documentation on using the basic registration form? Will enabling the Self-service registration for the application what you are after? If not, a little more detail on your flow and how you have implemented may help.

This post may help provide some clarity as well for an invitation flow. Keep in mind, this flow utilizes some paid features of FusionAuth, but you may be able to figure out some work arounds with the community edition.

This post talks about passing some parameters in a link that may help as well.

@jobclone20 I just took a look at the page for the FusionAuth Visual Studio Templates. It appears they are only for Visual Studio 2022.

@haziqt have you taken a look at the documentation on How To Us a Proxy? There are a few headers you will need to add.

@robert-regnier Unfortunately, it looks FusionAuth does not support this. I did find an
open issue that you may want to upvote if it is in fact the same issue you are experiencing.

You may also want to check out this blog. It talks about a custom domain using one of FusionAuth's hosting packages, but think it should work in your case as well.

Does anyone else have a similar setup? How did you implement it?

@jobcuatoi14, Since I work for FusionAuth, I obviously have a pretty strong opinion on this one. Beyond that, I still have a strong opinion as a developer in general. I will share with you my thoughts so you can take them under consideration.

I'm not going to tell you what you should and shouldn't do. Everyone's authentication strategy is their own decision. Personally, in general, I would recommend against building your own. Instead of listing reasons, I will pose questions for you to consider so you can come to your own conclusion.

Are you a security expert? If not, you will need to implement all the standards. Yes, you can use common libraries, but you will have to always stay up on the latest and greatest. Everyday you will need to check for vulnerabilities in every library you use. If something breaks, you will have to stop what you are doing on your core product and fix it. You also mentioned JWTs and there are many other well known standards out there such as OAuth. Knowing the recipe and executing it are two different things. You may read how to prepare Fugu, but do you really want to do that yourself or leave it to an expert?

Is authentication your product? If not, you will have to consider all the time you will be dedicating to authentication as a developer. How much better would your core product be if you spent that time focusing on it?

How much time do you have to dedicate to building your own auth? Even with standard libraries, you will have to build a lot. Probably more than you initially thought. I know you talked about using bcrypt for hashing, but are you aware of the concept of using salt with the passwords? If not, I would really recommend not doing it. If you are, that is just one more thing you will have to deal with. You mentioned the forgot password flow, but you will likely need other things like initial registration flow. What about updating user data in general?

What features do you need? Of course that comes down to what you are trying to protect. If you are just maintaining your small blog subscription, username and password may work. If it is more sensitive, you may need things like MFA. Will you need to allow social logins? Will you need to enforce password policies? Will you need to support passwordless login? Role Based Authentication?

Do you have time to maintain what you build on top of your core product? Once you have it built does not mean you can forget about it. Security is an evergreen process. The consequences of a lapse and impact on your product/company can only be measured by you.

I could go on and on, but I think for a forum post this gives a pretty good support of my recommendation.

Whatever issue you have with the other tools you mentioned or even FusionAuth itself, I would challenge you strongly to consider if the issue is easier to deal with than creating the whole system yourself. In my experience, it is usually easier to work around the issue than build your own.

I can't necessarily speak for the other products you have listed, but if you list some of your concerns with FusionAuth, I may be of some assistance.

Are you aware FusionAuth has a free Community Edition?

Also, I would recommend going through a FusionAuth Quickstart in the programming language of your choice to see how easy it is to get started.

Deciding which authentication to use is not a simple choice, I hoped this helped and didn't sound too "salesy".

I'd love to hear other's thoughts on this as well.

@valerii15298 said in can't use fusion auth react sdk when fusion auth server runs locally on fusionauth.localhost::

I followed react sdk example https://github.com/FusionAuth/fusionauth-quickstart-javascript-react-web/tree/main

I changed in kickstart tenant issuer to

"issuer": "http://fusionauth.localhost:9011"

and variables to

"allowedOrigin": "http://fusionauth.localhost:4000", "authorizedRedirectURL": "http://fusionauth.localhost:4000", "authorizedPostLogoutURL": "http://fusionauth.localhost:4000/logged-out", "authorizedOriginURL": "http://fusionauth.localhost:4000", "logoutURL": "http://fusionauth.localhost:4000",

and started fusion auth in docker compose, also specified env var:

FUSIONAUTH_APP_URL=http://fusionauth.localhost:9011

For react sdk use this config:

const config: FusionAuthProviderConfig = { clientId: "e9fdb985-9173-4e01-9d73-ac2d60d1dc8e", // even started my app under the same local domain redirectUri: "http://fusionauth.localhost:4000", postLogoutRedirectUri: "http://localhost:4000/logged-out", // serverUrl: "http://localhost:9011", // this one works serverUrl: "http://fusionauth.localhost:9011", shouldAutoFetchUserInfo: true, shouldAutoRefresh: true, onRedirect: (state?: string) => { console.log(`Redirect happened with state value: ${state}`); }, scope: "openid email profile offline_access", };

And when I log in and am redirected back to my app, fusion auth hook does not show me that I am logged in(it does not even send any requests I checked network). But when I strip everywhere fusionauth. prefix then everything works fine. Why does not fusion auth work locally with custom domains?

Cookies on my local app fusionauth.localhost:4000 are also saved after I logged in: https://freeimage.host/i/3FVbSJsWacky Flip

And when I click login button again (or invoke startLogin function from useFusionAuth hook) I am redirected right away to the app since I am logged in. But isLoggedIn is false and useFusionAuth hook does not recognize that user is logged in.

(I have mapped fusionauth.localhost to localhost in my hosts file locally)

#docker #react-sdk

Set SameSite=None; Secure explicitly on the FusionAuth Cookie: this tells the browser to send the cookie with all requests, even cross-site requests. SameSite=None requires the Secure attribute, meaning the cookie will only be sent over HTTPS. Since you are using http://, this won't work directly without HTTPS set up locally.

@Alex-Patterson tunnel rush said in Adding supplementary user data:

@evanm Yes you can use the sub inside of the JWT when making any API call to your backend. In your database this will be a unique Id for the user. You can even get more details about the user from FusionAuth by calling the User endpoints.

https://fusionauth.io/docs/apis/users#response-1

Thanks for sharing!!

@dan geometry dash lite said in LDAP:

@david-billings

Does FA remove users once they've been removed from LDAP?

If you use the LDAP as the source of truth, the users won't be able to login, but they won't be removed.

So, consider this scenario (no migration, just always going back to LDAP):

User A logs in successfully through a tenant configured with an LDAP Connector. User A has an account in the LDAP server. FusionAuth checks with the LDAP connector, passing the credentials. The LDAP server says "yup, User A is okay." FusionAuth creates a user. Time passes. User A is removed from the LDAP server. User A tries to login. FusionAuth checks with the LDAP connector, passing the credentials. The LDAP server says "User A is not found" FusionAuth denies the login.

But the user still exists.

Is there anyway to sync this and sync the users without each user having to login?

You want to sync the users between LDAP and FusionAuth without the user having to login? Is this a one way sync?

You could do a bulk migration using the Import User API if you have access to the LDAP database and can provide the password hashes.

That is the only option that comes to mind.

Thanks for your help, it was very helpful.