We have load tested our medium deployments to roughly 20 logins per second. It can vary quite a bit. We ship with PBKDF2 and a factor of 24,000. That configuration is the primary limiter to how many passwords we hash per second.

Tune it up to bcrypt factor 14, and it may take 3-5 second per hash. You can also tune the factor down from the default scheme to increase logins per second - it is a trade-off between security and performance.

And you can change these settings at the tenant or user levels: https://fusionauth.io/docs/v1/tech/apis/tenants
https://fusionauth.io/docs/v1/tech/apis/users

It depends, if you’re on an Enterprise hosting plan we can configure a certificate with your domain. So if your app is running at acme.com - we can add a certificate so that you can create a DNS CNAME record to our service using login.acme.com (for example) .

More on our plans here: https://fusionauth.io/pricing

@robotdan Ah, I missed that. I was looking at the response section, which had the registration. Thanks!

If you have purchased a high availability hosting plan we can configure additional URLs for you - such as login.example.com - and then FusionAuth would be in the same domain as your own application, and you'd be able to verify the domain.

This is not currently available.

The plan is to build out SMS templates that can localized and customized but no timelines have been determined.

That message means the user is not registered for the application you’re logging into. If you create a registration for the user you’ll see Authenticated.

More on this here: https://fusionauth.io/community/forum/topic/5/can-you-limit-a-user-s-login-authentication-access-to-applications-within-a-single-tenant/2

If you are using the Login API (/api/login) - this does not create an SSO session.

The FusionAuth Login pages do not currently use the access_token or refresh_token cookies for session management.

If you want the SSO feature - you need to use the FusionAuth login pages. This is the strategy outlined in the 5 minute setup guide: https://fusionauth.io/docs/v1/tech/5-minute-setup-guide

We do have a feature open to switch to token based SSO so that this use case would work: https://github.com/FusionAuth/fusionauth-issues/issues/358

Well, since we're talking about behavior based on a fix that isn't written yet, things are a bit theoretical. 🙂

Here's one approach we'd consider. An expired key pair cannot be used to sign a JWT, so we would either have to generate a new key pair ahead of the expiration, or start failing login operations. The former is a better user experience, so a user will either have to regenerate the key, or we would do it based upon a configured policy.

Also, wanted to be clear that we are aware of this limitation, which is why we set the default expiration period to 10 years (so we have a bit of time to solve this in the best way possible).

Hope this helps. Let me know if you don't have the information you need.

A good way to test the app is up and running is to run docker logs 27e4c9edd311 where 27e4c9edd311 is the docker container id, which is found by running docker ps|grep fusionauth.

If you are using docker-compose, you can also run docker-compose logs -f fusionauth.

Look in the logs for any errors. On successful startup, you'll see this message (with perhaps a different version message):

--------------------------------------------------------------------------------------------------------- ------------------------------- Starting FusionAuth version [1.16.0-RC.1] ------------------------------- ---------------------------------------------------------------------------------------------------------

As long as your meet our minimum database requirements in theory it should work. I do know that MySQL Group Replication is not supported.

Yes. You can view our plans here: https://fusionauth.io/pricing

Each plan has the same level of support whether you are hosting with FusionAuth or in your own cloud or data center.

You always get the same features whatever level you are at no matter where you host. That is to say, if you have a premium plan, you can host or we can, the features are the same. If you use the community edition, the features are the same no matter where you host.

However, there are feature differences between the premium and community plans. More here: https://fusionauth.io/pricing

Hiya,

I got an answer for you about sunset provisions.

We have discussed source code escrow options with clients in the past. We can also offer a source code release clause (in the event FusionAuth goes out of business). However, these are only options if you are on an Enterprise plan with a custom contract.

Hope that helps you make the right decision for your application(s).

You can use the post_logout_redirect_uri query parameter on the logout endpoint to configure where a user ends up after logout.

More here: https://fusionauth.io/docs/v1/tech/oauth/endpoints

Yes, you can provide the tenantId on the request as a parameter. More information here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#openid-configuration

No, but you can flush the index: https://fusionauth.io/docs/v1/tech/apis/users#flush-the-search-engine . From that doc:

This will cause any cached data to be written to disk.

Hi,

I think this was recently resolved via this issue https://github.com/FusionAuth/fusionauth-typescript-client/issues/16

Can you take a look and see if that looks like your symptom?

@robotdan Thanks Dan!