Open tilmann opened 6 months ago
Hi @tilmann and thanks for surfacing this issue.
The verifier code you showed is for webhooks — but should consider updating as well.
The decoder for Azure AD is here: https://github.com/redwoodjs/redwood/blob/d2b7f7fb4d70243616d9f9dcf7c5bfe1e6a4981f/packages/auth-providers/azureActiveDirectory/api/src/decoder.ts#L55
Would a sensible default (5 seconds. 20?) and then an envar to customize be a solution?
Hey @dthyresson,
thanks for the fast reply and the suggested solution. In https://github.com/nextauthjs/next-auth/pull/3071 the team decided for 10s. I would just go with the same value. I think you have a better understanding if we even need the envar. I would hope that this solves the problem for everyone.
I am currently running my system 5s "in the future" and the error is gone.
@tilmann Thanks for the next auth link, I confess I didn't look at it before -- and good to know that Azure AD has this known issue with timing tolerance. 10 seconds seems like the sensible default and it appears nextauth had a way to set a custom amount too, so some envier or setting feels proper.
What's the best way for us to test and confirm a fix? Would you be able to test a canary v7 release with an update?
@Tobbe If we modify the Azure auth package, could we publish just an update to that one package -- or would we need to wait from a new v7 rc?
Happy to test a published version. We are on v6 but I need to upgrade our Codebase at one point in time anyway.
We use Azure AD B2C and have been having this issue for more or less a year in our dev environments. Our org controls the clock setting/synchronization in Windows, so the only way for us to reproduce it is to let the clock go out of sync by leaving the computer running for several days, but it is quite reliable (and annoying when it does happen 😅).
What's not working?
Problem There seems to be a problem with the clock tolerance for azure tokens while verifying the jwt.
This leads to this error while developing on an irregular basis:
Solution There is an option in jwt.verify called clockTolerance. This was discussed here as well: https://github.com/nextauthjs/next-auth/pull/3071
It would be helpful to either set the clockTolerance as an option. (currently only issuer is allowed) or set this to a standard value like 10 seconds.
From jwtVerifier.ts:
How do we reproduce the bug?
The reproduction would be a redwood project with azure auth configured and then adjusting the local clock a few seconds to the past.
What's your environment? (If it applies)
Are you interested in working on this?