Entra(Azure) ID OIDC clock skew config item.

[ch0wm3in]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

As described in #339 it is still to this day impossible to configure Entra ID(Azure) OIDC where it actually works and signs in, without "disableIssuedAtCheck": true which seems to be an important security feature.

The clock skew seems to be something Microsoft does intentionally, paraphrasing from a microsoft related lib issue AzureAD/microsoft-authentication-library-for-js#512
The need of the clock skew is to avoid situations where the client clock and the token issuing service clock are not exactly in sync.

It seems there a mentions around the internet that you can disable the skew from within your Entra ID config but it seems to have been retracted since, and there is no official/public documentation on it.

Could this possibly be solved or made more secure? So instead of disabling the check alltogether, you could have a config item for OIDC where you can "loosen the skew check" to 5m or 10m when such issues arises from different providers not being 100% compliant.

Why is this needed?

I think it would be good to support Entra ID(Azure) so that the OIDC actually works as intended, and that you can make the "disableIssuedAtCheck": true less strict but not completely disable it.

[dopey]

Hey @ch0wm3in 👋, thanks for opening the issue!

We triaged and there was general agreement from our team that this could be a useful feature to help address the behavior you're describing. However, it's a non trivial amount of changes - it would require additions to this repo, smallstep/linkedca, and smallstep/cli to fully incorporate the changes. We don't have the bandwidth to take it on at this time, but we'd be open to accepting such a contribution from the community, .

If there's more engagement from the community (in the form of likes and comments, or folks letting us know they're running into the same behavior) we will reconsider our roadmap prioritization.

cheers 🍻