@atakan thanks for sharing the information.

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

@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!!

@mark-robustelli Thanks. I'll do just that

@laurahernandez I hope you are able to achieve the look and feel you are going for. I understand you would like to be able to show and hide the password dialog in simple themes and you are not the only one. Please be sure to upvote the issue here.

I understand using advanced themes may require more work, but ultimately it is more flexible that simple themes. Good Luck.

@mark-robustelli Yes, it's all working. After the logout flow executes, the sessions that were being left behind on FusionAuth are now being revoked properly. Thanks.

@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?

@mark-robustelli said in Is it safe to build my own authentication system for production?:

@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 gunspin 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.

Thank you for these thoughts and experiences very grateful

@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.

@owork138 Thank you so much for the detailed and thoughtful explanation. Your insights have helped clarify the likely cause of the confusion with the authentication setup in our FusionAuth application. Understanding that the lack of distinction in the session data may stem from FusionAuth’s default handling—and that customization in our Express.js logic might be required—gives us a clear direction to move forward.

We truly appreciate the time and effort you put into outlining potential solutions. We'll be reviewing our current middleware and exploring the recommended approach to better capture identity provider information during authentication.

Thanks again for your support!

@jay-saxophone383 I do believe you can get FusionAuth to work as you described here. Here are some links that may give you a little more detail.

SAML v2 with ADFS

OpenID Connect with Azure AD

Enabling Single Sign-On in an Organization

Product Update

As mentioned above, some of the features described are only available with paid planes and if you need to test them out, you will want to contact FusionAuth and see what can be worked out.

@mark-robustelli said in NetworkError when attempting to fetch resource:

@Survival Race, can you please give us a little more detail on how you are set up and exactly what you are trying to do. I see you are getting a NetworkError when trying to reach (auth.*.com). Is that an instance of FusionAuth hosted by FusionAuth or is that an instance of FusionAuth that you have deployed? How are you trying to access the resource ? Through a web browser or are you trying to execute an API call? The more information you can provide, the easier it will be to help.

If you have a paid plan which includes technical support, please open a ticket via your account portal.

Have any recent changes been made to the CORS configuration or FusionAuth app settings?

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.

@robin-singh said in Getting 403 : disallowed_useragent with Google Auth:

We have android/iOS app where authentication redirects to fusionauth login page.
And here we have Facebook/Google login setup.
Facebook and native login is working fine but with Google login getting Error 403: disallowed_useragent.

Is there any way to directly open sign in for google which will send data to fusion auth only.

Are you trying to open the login in your application? Maybe try to use the system browser to up the Google login and see if that works. Google disallows OAuth login flows inside embedded web views (like those used in many mobile apps).

This is not available today without some glue code.

Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs:

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success https://fusionauth.io/docs/apis/users#update-a-user

@d-chinguun-0301 No problem. Glad you figured it out. No need for apologies, if you were confused others may be as well. Now when they search here, they will have an answer. Have a great one

This is possible in a couple of ways.

First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:

When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.

Then the question becomes, how can you disable the hosted login pages self-service registration form?

To do so, take the following steps:

update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with not implemented or similar. However, a sinister user may still be able to post to the register endpoint and create a user if you are self-hosting, block access to the /register endpoint using a proxy if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the user object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.

The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.

@hamza-chouaibi Been having this same exact issue for the last one week. When I stumbled onto this and applied the suggestions here is when it now seems to work. I use the .dev TLD instead.