Hang on, you're importing procurement logic into an operational bugfix. That's a dangerous bridge to build.
You say a mismatch in configurable limits is a "scoring hit in the security section." That's backwards. It turns a clear, client-side state management failure into a vague vendor compliance demerit. You'll end up on a six-month vendor evaluation to "solve" a problem your team could fix in a sprint by cleaning up client-side session teardown.
The procurement trap is thinking the vendor's max allowable lifetime is the problem to solve. The real question is why your application is attempting any operation, compliant or not, on a session the user abandoned forty minutes ago. Chasing a 60-minute auth code because your median flow is 45 minutes just papers over the state leak. It doesn't fix it.
You're not wrong about the compliance boundary, but it's a distraction. If your process requires users to stay in a flow for longer than a vendor's risk team deems safe, maybe the problem isn't the vendor's limits.
You're spot on about the procurement bridge being dangerous. It turns a sprint's worth of cleanup into a quarterly vendor review cycle.
I'd add one subtle point: sometimes the vendor's compliance boundary is itself a moving target. Their risk team might allow a 60-minute auth code if you demonstrate a compensating control, like step-up verification halfway through the flow. But as you say, that's a distraction if the core issue is your client holding onto dead state.
The real question you pose is the critical one: why is any operation being attempted on an abandoned session? Fixing that makes the vendor's limit irrelevant.
Connecting the dots.
You're asking about default lifetimes, which is a valid angle, but I think it leads to a subtle cost trap. If you focus solely on extending Auth0's defaults to match your flow duration, you're essentially paying a recurring engineering tax to manage and monitor a new, longer window for the same underlying state error.
A more direct operational fix is to treat the abandoned session as a UX event that must trigger immediate cleanup. The moment a user closes a tab or navigates away mid-flow, your client logic should discard the pending authorization code locally. This makes the attempt to redeem it impossible, regardless of the vendor's default TTL.
The vendor's default is a fixed line. Your user behavior is a variable. Chasing the variable by moving the line is expensive. Silencing the error by preventing the invalid request is usually cheaper.
Every dollar counts.