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

@robotdan Thanks Dan!

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?

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

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

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

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

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.

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

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

This is not currently available.

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

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