Our security is changing, so I'm updating an Angular SPA application to use OpenID Connect. I found a nice library to help set things up. However, I've run into an issue where it tries to access the JWKS endpoint unsuccessfully; it's blocked by CORS even though my application has been whitelisted.

Neither I nor my cyber security counterparts are able to explain the issue. Please assume we've configured both ends correctly.

The recommendation I received was to switch to a library that didn't require that endpoint (in other words, skip the JWT validation). I'd most likely switch to this one; apparently another application is using it successfully.

From what I can tell, the JWKS endpoint is used to verify the authenticity of tokens. Dropping it makes me a little uneasy.

What security risks does this open us up to? Should I push back on this?

  • 1
    Isn't the JWKS resource on the same server as the OpenID provider, where you do XHR calls to the token endpont anyway? So it sounds like CORS is just not configured for JWKS. Could it be a reverse proxy error? Anyway, in the front end, if JWKS and the token resources are served from the same server, you are already verifying the source using TLS, which decreases the risk of not verifying the tokens. Not a recommended practic, but worth keeping in mind for an overall risk assesment. – Geir Emblemsvag Sep 7 '19 at 8:03
  • Thanks for the insight. I do suspect a reverse proxy misconfigured, but it’s far easier for them to tell me to change then to get someone to actually fix it. – ricksmt Sep 8 '19 at 4:08

OpenID uses JWTs to provide access and ID tokens. These JWTs tell us everything we need to know for those tokens. However, you need to trust the JWT. And to do this you must have the public key available from a source other than the JWT. You can:

  1. Get the public key from the JWKS (.well-known/jwks.json) endpoint.
  2. Get the public key from some other trusted location. This other location can be a database, configuration file, something reasonable.

From the perspective of validating the token, I have not heard of any issue with validating a JWT against a public key found elsewhere.

However, you want to be able to rotate your public key if need be, since the corresponding private key is critical to securing the JWT tokens. If you take option #2, you risk having public keys scattered all over the place that would make it harder to update all the public keys. So if you take route #2 you want to be sure you can rotate your keys.

Also, if the OpenID Connection provider is outside your control, they could change their keys and you wouldn't necessarily know.

The Signatures and Encryption section of the OpenID spec says:

The OP advertises its public keys via its Discovery document, or may supply this information by other means. The RP declares its public keys via its Dynamic Registration request, or may communicate this information by other means.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.