It's a subtle difference, but one-time use refers to the value of the refresh token, which you use against the /oauth2/token endpoint to get a new access token via the refresh grant.

A sliding window refers to the refresh token itself, which has a unique id which stays the same, even as the value of the refresh token changes.

So if you had a refresh token with a lifetime of 4 hours, a sliding window and one time use configured, you might end up with something like this:

at creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value RNhY5yE39t1o2FXKxgyH, lifetime 4 hours when the RT is presented to the /oauth2/token endpoint 3 hours after creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value Fh95KZLfSMjMNxpR5B4c, lifetime 4 more hours when the RT is presented to the /oauth2/token endpoint 3 hours later: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value baHneP4s0hBHPEk88GPC, lifetime 4 more hours

More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2925

@mark-robustelli it was my fault, it turned out someone in the team created a lambda operation that was running which changes the user's data as soon as the user signs up which overrides the initial data.

Thanks for your reply though.

Duplicate post

@mark-robustelli Sure,Thanks!
If you find anything please let me know

Here's the PR making the doc better:

https://github.com/FusionAuth/fusionauth-site/pull/3371

@celiaruby127

Also, sorry for my late reply, I saw just now that I had to activate notifications.

@aman-c Have you been able to follow the Next.js quickstart?

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.

@dan Thanks for this. I've tried your suggestion but the result isn't very pretty. Freemarker templates are a new one on me and once I dig into the default templates, when creating a new advanced theme, it's quite complex enough to begin with!

I am usually the type to prefer more customisation than less but maybe there could be a couple of "cookbooks" or example templates somewhere? It's nice to see some visual examples in the docs but without knowing how to get there, it's a little disheartening.

Hi @jamesbaxter . Sorry, just saw this now. I don't have the example app available. Sorry!

Oh, it's still an open bug - https://github.com/FusionAuth/fusionauth-issues/issues/2574. I'll ask there.

@tschlegel There are differences between the database search engine and using open search. Some of the searches are more limited with the database search engine.

"If you don’t need advanced searching capabilities, you may be able to use the database search engine for large installations. This is not a use case FusionAuth tests, so ensure you provision your database with enough resources and benchmark your typical use cases."

@rohit How often does this happen? Do the logs always state the same thing?

@lhatter, The FusionAuth recommendation is to leave all password hashing plugins in place once installed.

See Deleting Plugins on the Custom Password Hashing page.

I upgraded. I haven't tried a new install nor do I want to. I understand why it's happening. Is it something you can fix in a future update, without my having to start over with a whole new install?

@Alex-Patterson Can you please look into this one , thanks a lot in advance.

Thanks Alex. I went back and looked and it doesn't seem I can even turn that option on. Its set to First Party and when I try to set it to Third Party I get this:

7c9c6e5d-95d3-4c0b-9055-dfd713a5236a-image.png

So that doesn't really answer the question as to why fusion auth is redirecting to the "consent" endpoint. This process is kicked off via the normal "authorize" endpoint so I don't think email templates are in play either.

@aman-c FusionAuth is completely running outside of Next.js. So it all depends on what you are using to make the call to FusionAuth.

My suggestion would be to implement a version of our React SDK
https://fusionauth.io/docs/sdks/react-sdk

Then anything clientside that needs details you can use the built in hooks, anything serverside you can use the cookie that sits at app.at or for identity app.idt.

If you have been using our quickstart you are most likely using next-auth which could be causing issues with the implementation. We have had a lot of internal discussion about removing this methodology moving forward to simplify our Next.js suggested implementation.

You can find out more about our cookies that are set in our Hosted Backend details.
https://fusionauth.io/docs/apis/hosted-backend

@gubbasainithin123 Can you tell us a little more about what you are trying to do and add a few more details on how you are getting this error message? How is you application configured? Maybe some of the code if possible. Make sure to remove any secrets or private info.

Have you checked out Lambdas? Sounds like you may be able to do what you need with that.