@alan-rutter When it comes to account recovery in a passwordless login system, the most recommended method is to use a self-service approach. This means allowing users to recover their accounts themselves, which not only saves administrative costs but also saves the user's time. The simplest form of account recovery, and the one most amenable to automation, is a “forgot password” flow. This should be part of any Customer Identity and Access Management (CIAM) system.

In the context of passwordless authentication, this could involve sending a one-time code or a magic link to the user's registered email or phone number. The user can then use this code or link to authenticate themselves and regain access to their account. This method is secure and user-friendly, as it does not require the user to remember any passwords.

For more information, you can refer to these articles on account recovery and passwordless authentication.

@david-gonzalez I created a new user test@test.com and added the FusionAuth Registration. I granted it the Report Viewer role and was able to log in and see recent logins on the Dashboard. (I assume that is what you are talking about.) I got curious and removed the Report Viewer role and added the Event log viewer role. That allowed the test user to see the Dashboard as well. Will one of those two roles work for you?

@prince-b What scopes are you requesting?

@zaalbarxx Currently, FusionAuth does not support the use of macros for reusing content across different email templates. There is an
open issue on GitHub discussing this feature. I suggest you up vote it.

Hmmm.

Did some research and there's no way to straight forwardly have Discord delegate user management to an IdP.

This is in contrast that with other tools like Zendesk which let you do this pretty easily.

Of course, you can go the other way (have users log in with Discord) but that's not what you are asking.

There are some workarounds, but they require custom discord development. Here are some options:

Create a discord application that adds users to a server based on the oauth2 flow with the guilds.join scope. set that application up in a way that people need to sign in with FusionAuth and link that signup to their discord account. Your discord app that handles said oauth2 flow. Then you add users through that app instead of invite links. Use a public server but lock channels behind a role which gets added upon authorizing with FusionAuth by your bot. You could also use linked roles with a general access role people can opt into, if they fulfil the requirements set by that role (which you could control via registration at FusionAuth).

There's lots of documentation on creating discord bots but I don't have a specific example of any of these solutions, sorry.

@david-4 , Is this what you are looking for? Using Replacement Variables

I've tested on 1.50.1 and I am able to see the usernameClaim in the response body.

However, that field is something that is not set by default and will only show up if that field has a value in it, otherwise it will not be in the response body.

@alan-rutter

Thank you for your answer, I will check that out, but it is really blurry in my mind as of now!

@Alex-Patterson No, I've been using 1.50.1 version of FusionAuth (read from the admin panel) all the time. The only thing that changed was provider version. Like I said I can just switch between versions and it will start/stop working immediately, so I assume that version 0.1.106 may add some implicit parameter which changes something.
I just checked it after using docker-compose down -v and docker-compose up (fresh installation) and after running the Terraform the error still persists. What's interesting is that I've checked the diff between 0.1.105 and 0.1.106 on FusionAuth Terraform repo https://github.com/FusionAuth/terraform-provider-fusionauth/compare/v0.1.105...v0.1.106 and it does not seem that anything that could be related was changed there, maybe it is related to Go client or something ?

EDIT:
Ok, I found the culprit, looks like between 0.1.105 and 0.1.106 there is some change that automatically sets this to either false (106) or true (105):

Application -> Scopes -> Provided Scopes
Here there are some default scopes, address, email, phone and profile.

The problem here is that it looks like the Terraform provider currently does not allow to set these variables in schema, so basically we are blocked between older version with unsupported configurations like theme's oauth_consent and newer version which handles these scopes inproperly (we can change it manually, but obviously each deployment will cause the values to reset back to false).

https://github.com/FusionAuth/terraform-provider-fusionauth/issues/277

I hope this will get resolved quickly since right now it is quite a blocker.

@mark-robustelli , thanks the issue though was my web app was sending the nameid format as persistent after removing it the issue was resolved.

what about the password start event? will webhook receive a event for a user who does not exist in fusion auth?

This will be good feature especially if slow migration is used for migrating users

Coming back to report my experience for future reference.

I tested going from version 1.18.7 up to 1.50.1 and it was actually possible to go straight from one to the other, i.e. install 1.50.1 and let FA automatically upgrade the database.

If you are using custom themes, many new templates have been introduced and will be missing. A small issue that will come up in this case (specifically after version 1.37) is that the index page will be broken. This is because a new index template has been introduced and will now be missing. You can circumvent this by either appending "?bypassTheme=true" to the URL, or going directly to the login page "/admin". You can then login and fix any theme issues through the dashboard editor.

Another issue I faced was that for some reason (didn't look into it), any changes I made to my custom themes would silently be discarded. I had to duplicate the default theme and start from scratch. Given the many differences and depending on your use case, this may be a good idea anyway.

@mark-robustelli thanks for the documentation link. I used a version of the "Logout Requirements" example to redirect to an endpoint that removes any fusionauth.known-device.* cookies before redirecting back to the application.

Do you think the Hosted Backend should remove fusionauth.known-device.* cookies when it removes the other tokens, at least in the case where fusionauth.remember-device is false?

Otherwise, it seems certain we will hit the HTTP 431 error whenever an application is accessed on a shared device with ~100 users. Or is the Hosted Backend not something FusionAuth envisions people using in production?

@kasir-barati When you say "I dunno if we can use them to change what Get /me endpoint returns", you might want to check out the UserInfo Populate Lamba.

Hey @dan,

I guess I need something similar for user.data.username. I need to define a rule on this custom user data to be unique in my app or tenant. As of now I really do not care about tenant or app since I only have one tenant and one app in my FusionAuth.

So I've asked this Q&A and I need to enforce uniqueness for this data. But dunno how to do it. Any suggestion?

I tried to specify both username and email and I got this error:

{ statusCode: 400, exception: { fieldErrors: { 'user.email': [ { code: '[blank]user.email', message: 'You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].' } ], 'user.username': [ { code: '[blank]user.username', message: 'You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].' } ] }, generalErrors: [] } }

So basically I guess my best bet is to manually enforce uniqueness of username in my backend. But it could have been less cumbersome if I could delegate it to FusionAuth.

I guess what I am trying to emphasis here is the fact that just by saving username in user.data we will be able to have both username and email but applying rules such as uniqueness would require more manual labor. Cannot we just tell FusionAuth to make sure that user.data.username should be unique in that app or tenant?

Side note: Since my question is deviating from the OP I'll create a new post and reference this one.

@hanumant-sidraya Can you please clear up a few things.

It sounds like you have customers that have their own IdP. When you say "the customer has exposed the API for authentication.", what does that mean. They have an API that can confirm their identity?

If you have the APIs and authentication working with the customer's IdP, have you tried enabling the Two Factor Authentication for the user? Go to your user details screen in FusionAuth and then click 'Enable Two Factor' from the dropdown in the upper right hand corner?

For more details, you can refer to the Two Factor API documentation and the Enable Multi-Factor Authentication API documentation.