search

smallstep / certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
https://smallstep.com/certificates
Apache License 2.0
6.8k stars 445 forks source link

Entra(Azure) ID OIDC clock skew config item. #2055

Open ch0wm3in opened 3 weeks ago

ch0wm3in commented 3 weeks ago

Hello!

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 https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/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 commented 2 weeks ago

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 🍻