That is correct. For security reasons, we do not provide feedback if the user exists but the password is incorrect, vs the situation where user does not exist.

This is true both in the hosted login pages and the login API response codes. That's what we recommend if you build your own pages as well.

Select Start > Settings > Time & language > Language & region. Under Preferred languages, select the language you want to remove, and then select Remove.

A refresh token is opaque; you cannot validate it yourself.

The general pattern for validating a refresh token is to use it to refresh the JWT, and if the refresh attempt fails, that indicates the refresh token is no longer valid.

You could also retrieve a user’s refresh tokens and compare it to the ones returned by FusionAuth.

More details:

https://fusionauth.io/docs/v1/tech/apis/jwt#refresh-a-jwt
https://fusionauth.io/docs/v1/tech/apis/jwt#retrieve-refresh-tokens

I value the insights and guidance you provide, I will try to figure it out for more.

The easiest way to do so is to listen for the jwt.refresh-token.revoke event.

It's documented here: https://fusionauth.io/docs/v1/tech/events-webhooks/events/jwt-refresh-token-revoke

In particular, you have the date of the revocation (the end of the session). If it is an individual session revocation, you have the start date, which is the startInstant inside the events refreshToken field.

If your webhook processor does the subtraction of these two values, you'll be able to find and record the duration of the session length.

@dan And how do you add a button? Do you have an example? if I want to delete the token and make a forward redirect the user to another page (the login, for example).

No error in registering existing users.

@jbtruffault Thanks! The admin UI has minimal customization, but appreciate you raising the issue. It's on the list.

@raghebmichael said in Manually verifying a JWT:

Something is very wrong. I don't know if this is something anybody else is facing, but I changed to a RS256 key and used the public key on jwt.io and it is still invalid. I cannot validate a JWT outside of /api/jwt/validate. This is a really big deal to me to be able to do something as simple as validating. Please let me know if I am in error, but if I can't get this to work I cannot continue using fusionauth and that's a big bummer to me as I had high hopes for this service.

b63ceaca-e17c-48e4-b7cc-fe757eff696f-image.png

This is exactly what I was looking for to solve my problem.
Thank you very much.

@g-natsoulis

Hiya, can you explain a little more about what you are looking for? I'm not quite sure what you mean by "an OTP provider for an Exchange server that has ADFS authentication set up?"

@fusionauth-0

Hmmm. So you are saying that:

you can connect from the ec2 instance to your postgresql instance. you can connect via the web to the fusionauth instance, but it is stuck in maintenance mode.

Where is the postgresql instance running? Is it on the same ec2 instance as FusionAuth?

What value are you putting for the hostname?

@langnerfrancesco What version of FusionAuth are you using?

What version of postgresql?

@vvicazz That's great news!

@bharath-yadavally You could absolutely use the 2 step approach you outlined. There are two different approaches that have different strengths and weaknesses.

The tradeoffs are that if you make those two calls, you're depending on the identity provider to be up and available to your backend service. You're tightly coupling the backend service to the identity provider.

That can work fine, but as you scale, more and more backend services will be making those calls, and the idp and speedy connections to it become more and more critical to your application.

Contrast that with the webhook approach, where the data is pushed to every backend service, and only when a user is deactivated. In this case, there'll be far less coupling with the identity provider, at the cost of more complexity on the backend service side.

Hope that helps.

@kushalborda1997 Hiya,

We recently updated the documentation to make it more clear you shouldn't use the /api/jwt/reconcile endpoint for any identity providers except the external JWT provider. We'll change the application to make the error message clearer; here's the tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/2074

You should use the OIDC provider and the complete login endpoint. Here's documentation that should help: https://fusionauth.io/docs/v1/tech/apis/identity-providers/openid-connect#complete-an-openid-connect-login

Hope that helps!

@didier I'm not sure I understand.

You are saying you want to send the registration email yourself, not automatically with FusionAuth?

(There are two possible verification emails. One is for a user creation, which verifies their email whenever someone creates a user, for any application. Another is for registration verification, which again checks their email but only when someone registers for a certain application.)

If that is the case, use the skipVerification and skipRegistrationVerification settings if using the API. There are analogous settings in the admin UI as well.

More documentation here: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

and here: https://fusionauth.io/docs/v1/tech/core-concepts/applications#registration

and here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#email

@dan

User logs in through authorization code grant flow

Here goes the refresh token settings for the application:

e34e22da-b37b-41e6-8816-88b43a8cbddd-image.png

FusionAuth version being used is 1.36.6

Thanks,
Vindhya

@alison-rafaelc Hi Alison,

It depends on how you architect the FusionAuth system, but in our FusionAuth cloud system, we see downtime of seconds to minutes for system upgrades (depending on the number of users and the data being migrated). We get this by swapping out one node at a time, running in an 3+ node cluster. Some details here: https://fusionauth.io/docs/v1/tech/installation-guide/cloud#upgrade-duration

Worth noting that you control when you do the upgrade, unlike a typical multi-tenant saas.

We have a number of customers and community members with thousands of tenants and millions of users so the numbers you mention seem fine. I'm glad you were able to stand up a FusionAuth cluster and load test it.

Zero downtime upgrades are something we've discussed internally and have a strategy for, it just hasn't made it onto the roadmap yet.

If you'd like to have a discussion with a technical sales team about FusionAuth and SLAs, I'm happy to have someone reach out to you.

@imapotato Heya,

FusionAuth isn't really an AD/LDAP replacement. It doesn't support older protocols like RADIUS, Kerberos or even LDAP fully.

When we are talking about machine to machine communication, we are referring to the client credentials OAuth grant. You can read more about that in the links below:

https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

https://fusionauth.io/docs/v1/tech/core-concepts/entity-management

@quent I understand your position, and we appreciate the feedback.

Can you please create a github issue linking to this forum post and with as much detail as you can provide (including, perhaps, sample logout urls provided by IdPs you are interested in)?

https://github.com/fusionauth/fusionauth-issues/issues