In what case would it make sense to set the default refresh duration to be the same as the access token lifetime? In that case you may as well just disable refresh tokens entirely. If we allow setting this equal to or very close to access token lifetime, I foresee customers running into issues. Would it make sense to validate that RefreshDefaultDuration is strictly greater than access token lifetime, and raise an error if this is not the case?

Yeah, that makes sense. I've added a validation to catch those cases.

It errors out if the constraint of refresh token lifetime < access token lifetime, since debugging why refresh tokens aren't issued would become even harder if we fail silently.

s/should/must

It would also be nice to know if there were a way to catch if this were not the case, and error if so.

For now, I suppose we could just check for a zero-valued DeploymentValues and complain?

The closest I can think of is checking if a session's default duration is not equal to 0 (the default)?

Since a session duration of 0 doesn't make sense conceptually.

So prepending something like

// Check if values appear uninitialized
      if access == 0 {
          return xerrors.New("sessions configuration
   appears uninitialized - ensure all values are 
  loaded before validation")
      }

Don't forget to also add a test to hit the code path you added to check for uninitialized default duration