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!

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.

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

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!

That is correct. Each user can have one email address, one username, or both. Either of these values can be used to login, and therefore the values are unique within the tenant.

We do have a username field on a registration, but it is not used for login.

There's a github issue open for multiple identities: https://github.com/fusionauth/fusionauth-issues/issues/1