TL;DR Okta doesn't enforce expiry checks on signing certificates for identity providers, and you have no other option but to accept it.

I use Okta regularly, for both personal and corporate projects. They're generally speaking, pretty great. Gartner's Magic Quadrant names them as a leader of the space and they're a solid choice for authn and federated authn.

I was pretty surprised today to discover that Okta do not check expiry dates on Identity provider (IDP) signing certificates. That is to say that if your application uses Okta to handle SSO, and you've setup an IDP for your authentication system (e.g. Azure AD, Pingfederate, Keycloak etc.) when the signing certificate expires login will continue to work.

After a days-long investigation Okta support confirmed to me that this is what's happening, and since it's not documented anywhere I wrote this blog post to save others wasting time. At the time of writing Okta do not document this behaviour, in response to my support request they implied that they might document it in future but the response was very non-committal as if it wasn't something they wanted to admit (opinion/speculation).

What's the problem?

Users that shouldn't be able to sign in, can sign in(!) using an IDP with an expired signing certificate. Sounds serious, but read on...

Who cares about signing certificate expiries anyway?

A lot of SSO specialists will tell you that signing certificates having an expiry in the first place is pretty ridiculous. They're used to verify that the party sending you a SAML Response is the right party, they're trusted secrets exchanged at IDP setup time and don't really need to expire, it's one of the many quirks of the SAML specification.

Why does it bother me?

Okta highlights IDP settings where the certificate has expired in BIG RED LETTERS, as if it's an error condition. I expended significant effort ensuring that my application would hassle my users to make sure that they replaced their signing certificate before it expires. I waste time on a regular basis with users replacing those certificates.

If my user's are working to the spec, and give me a certificate with a short expiry, they should have a reasonable expectation that it will stop working at expiry time. Okta does not give us an option to enforce this.

Why won't Okta fix it? Why should they do?

I can only imagine the storm it would cause if Okta change this behaviour now, people who stopped worrying about renewing certificates years ago suddenly locked out of their applications, a nightmare of people renewing certs they had forgotten they even had, nevertheless....

Client's security teams don't like a service that ignores the specification, there should at least be an option to enable the behaviour. If a client of mine wants to rotate their certs every six months, despite the negligible benefits of doing it so regularly, that should be their call to make.