but I am going to move on for now and assume it is not a FusionAuth issue.

Great. Let us know if there turns out to be a FusionAuth issue.

Added missing db migration notices for 1.21.0 and 1.22.0.

Looks like this is a known issue: https://github.com/FusionAuth/fusionauth-issues/issues/978

If you could chime in on that bug with any additional details, that'd be really great at helping us track down the issue.

Cheers!

Can you provide more details about what you are seeing? Are you working through a blog post? What version of FusionAuth? What version of .NET core? How have you configured FusionAuth?

Thanks!

Sorry, that functionality isn't available in the UI.

You can improve the performance of FusionAuth.

Like most applications, you should load test your particular situation. Will you have a lot of registrations? User searches? Logins? Will traffic be steady state or come in waves?

FusionAuth tends to be CPU bound when it comes to logins, because that's the goal of password hashing algorithms.

In general you can scale FusionAuth two ways:

vertically. This means using a bigger server. horizontally. This means using more servers. FusionAuth is 100% stateless and can scale with as many nodes as you'd like.

Don't forget that FusionAuth isn't an island; make sure that the database FusionAuth is using is scaled appropriately, as well as Elasticsearch, if applicable.

Here are some specific numbers that may be helpful to you: https://fusionauth.io/community/forum/topic/8/what-level-of-performance-can-we-expect-with-using-fusionauth-as-an-idp

For detailed answers about your specific use cases, we recommend purchasing a support contract so that we can dig into particulars. You can do that here.

@dan I was trying to use the standard register interface from fusion. If I check that I want to use "username" for example, the registration form removes the email option. To circumvent and get both email and username I had to create my own register form.

If you have an API key configured, you can use the User API to modify a password: https://fusionauth.io/docs/v1/tech/apis/users/

FusionAuth does not have a built in email server, so you need to configure SMTP in order to use the forgot password option. (Of course, you'd need to have set that up before). See the email tab here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants/#email

If you have a FusionAuth cloud account, open a support ticket.

There are no other supported options. You could try to modify your database if you have direct access to that, but this is unsupported.

It works! Thanks!

You can increase the timeout of the login request to a connector. If you sign in to the admin UI and navigate to "Settings" and then "Connectors", you can modify either of these settings:

"Connect timeout" "Read timeout"

The default value for these is 2 seconds.

There is more documentation on this topic here: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/

You can also change them via the API, if that's more in line with your current workflow. That's documented here: https://fusionauth.io/docs/v1/tech/apis/connectors/generic/#update-the-generic-connector

No, those tokens are completely de-coupled from FusionAuth (in a fundamental way, that is the point of those tokens).

There are revocation strategies however, but they require some additional work.

Here is one strategy we have documented: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts/

This is a common issue, as there are a couple of prerequisite settings that you need to configure in order to get refresh tokens. When you are trying to get a refresh token and not seeing it, you should double check the following items:

you are passing a value of offline_access whenever a scope parameter is present. you have configured the application to generate refresh tokens if you are using OAuth, in the UI, it is in the OAuth tab; the field is Generate Refresh Tokens if you are using the Login API, it is in the Security tab under Login API Settings; the field is Generate Refresh Tokens. you are passing the client_id to the refresh grant request. This is required unless you are passing the Authorization header (which has the client_id in it). the user is registered to the application for which you are issuing a refresh token.

Yes.

To ensure compatibility, I would recommend keeping your client library in sync with the version of FusionAuth.

For example, if you have 1.21.0 installed, that would mean ensuring you use the 1.21.0 version of the Python client.

It sounds like you're asking if you can modify the issuer claim.

You can control the "Issuer", or iss claim, in two different ways:

You can set it in the tenant config, where it will apply for all JWTs issued for that tenant. You'd modify that by navigating to "Tenants", then your tenant, then "General". Modify the "Issuer" field value to be login.example.com. You can set it at the individual JWT level by modifying the JWT populate lambda. You would do this if you wanted to have a different issuer based on some information from the user or registration data. (This does not appear to be the case here, just including this for completeness.)

I'm not clear if you have more than one tenant in your system; if you do, you can either change the "Issuer" setting for the default tenant (which is what is provided when no tenantId is on the URL) or request the endpoint with a tenantId appended, like this:

https://login.example.com/.well-known/openid-configuration?tenantId=<tenantid>

Yup, you can check out our test script repo here: https://github.com/FusionAuth/fusionauth-import-scripts

You need to have ruby installed, but there's a script under testing in that directory that can import a large number of users (1M is the default).

Loading 1M users to a basic FusionAuth cloud instance in Europe over a home network connection took about 40 minutes.

If using the API, you should receive a 203 on Login once you attempt login with the correct password. Your application should check the status code and send the user to the appropriate place to change their password.

If using the hosted login pages, you should end up on the /password/change page after logging in.

That should work ok. The only reason not to do it this way - is because you’re sort of emulating the OAuth frontend’s usage of this API which in theory is subject to change.

Re: state, additional key value pairs will be stored, however if our front end is consuming the URL, you won’t have access to the API response which will contain that state information.

This seems like a bug. Please file it here: https://github.com/fusionauth/fusionauth-issues/issues

This partly depends upon if you host FusionAuth, or if you purchase FusionAuth Cloud. In most cases, updates will will be zero downtime, others may require an outage depending upon the type of db migration required.