JSON Web Keys (JWK) Missing Certificate Chain

I am trying to integrate SSO from Okta into our application to generate JWT using the Authorization Code Flow. I have a developer account. I have followed the instructions for adding my application, added groups, associated people with the groups, altered the default authorization provider with added custom claims and new scopes, and adjusted the default identity provider to public/private key authentication type. I have used the token preview under the authorization provider to ensure the JWT looks correct. The final step for using the JWT involves validating the signature on the JWT using the JSON Web Keys. The metadata uri flow is the same as with Azure identity server such that the URL “/oauth2/default/.well-known/oauth-authorization-server” returns the correct information including the jwks_uri pointing to the keys. The problem I am having I am having and looking for a resolution is that the JSON structure returned from the jwks_uri URL does not include the x5c key and value. This is what is returned:


I removed the values for this post. I should also have the x5c and the x5n values according to the specification. Researching this further in the documentation, it indicated I should edit the Client Credentials of the Application to change it to specify the authorization type, however, there is NO edit available for the Client Credentials.

Can anyone tell me what I am doing wrong?

The absence of the x5c key in the JWKS (JSON Web Key Set) response from Okta is not an error. You can still validate the JWT signature using the provided n (modulus) and e (exponent) values.

Here’s what you need to do:

  1. Use a JWT library that supports JWK format with n and e values.
  2. When validating the JWT:
  • Match the kid (Key ID) from the JWT header with the corresponding key in the JWKS.
  • Use the n and e values to construct the public key for signature verification.
  • Verify the signature and other claims (Ex: iss, aud, expiration time).

Remember, the x5c key is optional in the JWKS format. Its absence doesn’t prevent proper JWT validation.