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

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

Ah, looks like someone else already shared a fix. https://github.com/FusionAuth/fusionauth-python-client/pull/6

There are a few things to consider.

how long tokens live for what happens if permisssion are modified in FusionAuth but the protected resource still allows access? any performance worries due to a large number of accessToken validation calls being made by the protected resource.

With the first approach (validating the access token without communicating with FusionAuth) the holder of the token will be able to access your API as long as the token is valid (unless the API server communicates periodically with FusionAuth to check the validity). In addition, changes to user privileges won't take place until the JWT expires and the client retrieves a new access token using the refresh token.

With the second approach, if a token is revoked in FusionAuth (if for instance the user is disabled) the access is cut off immediately. The cost is that you're making an additional network call every time, which has a performance impact. Note that if you could use the userinfo endpoint instead of the token if you want updated user claims. The token endpoint isn't going to give you that information, just a yes/no depending on if the token is valid.

So it's hard to make a recommendation without knowing what the consequences of unauthorized access to your API or protected resource would be. It also would be helpful to know the expected traffic; if it is expected to be low, the performance impact of the second approach will be minimal.

@bfpgresearcher Happy to help 🙂