JWKS endpoint

IAM uses digital signatures to prove the authenticity and integrity of issued tokens. A recipient of these tokens must properly verify the tokens' digital signatures before extending trust to the tokens.

To validate a signature, the recipient needs a copy of the corresponding public key used by IAM during the signing process. To achieve this, IAM could provide the recipient with a copy of the public key or an IAM URL to query and download a JWKS (JSON Web Key Set) containing all the signing keys IAM currently uses.

IAM already provides a JWKS endpoint as part of the OAuth 2.0/OIDC authorization server. This endpoint includes all keys on the authorization server and remains unchanged. The JWKS endpoint described here is an IAM-wide REST endpoint that can be used independently from OAuth/OIDC. The endpoint's response contains all IAM keys used for signing.

The JWKS endpoint response includes public keys from the following plugins:

  • JWT Ticket RSA Signer Settings
  • JWT Ticket EC Signer Settings
  • Oauth 2.0 and OIDC Private Key JWT Client Authentication
  • OAuth 2.0 and OIDC JWT Access Token Private Key Signature
  • OIDC ID Token Private Key Signature

JWKS endpoint - example

This section provides an example URL of the IAM-wide JWKS REST endpoint exposed by IAM, as well as an example response returned by this JWKS endpoint. The response will contain all the keys that IAM uses for signing purposes.

Example URL:

 
Example
https://iam.host.com/auth-login/rest/public/jwks/

Example response returned when querying the above URL:

 
Example
"keys": [
    {
      "kty": "RSA",
      "e":   "AQAB",
      "use": "sig",
      "kid": "383d3a6d0774813c",
      "alg": "RS512",
      "n":   "xBMU3...86OMQ"
    },
    {
      "kty": "RSA",
      "e":   "AQAB",
      "use": "sig",
      "kid": "f4a88e60e5d2c2fa",
      "alg": "RS256",
      "n":   "qQCXF...YN84-Q"
    }
  ]
}

Configuration to enable the JWKS endpoint

  1. Go to:
    Loginapp >> Advanced Settings
  2. In property JWKS Settings, create and edit a Loginapp JWKS plugin, as follows:
  3. In the property Cache-Control Response Header, you can configure a Cache-Control response header for the JWKS endpoint. Multiple, comma-separated values are allowed. For example: public, max-age=3600. Here public means that reponses can be cached in a non-private, shared cache. max-age=3600 defines the maximum amount of time in seconds that fetched responses are allowed to be used again.
    If the setting is left empty (default), the Cache-Control response header is set to no-store, no-cache, must-revalidate. This means that returned responses
    • should either not be stored (no-store),
    • or can be stored, but should be validated with the origin server before each reuse (no-cache),
    • or can be reused for subsequent requests to the same endpoint if fresh, but should be validated with the origin server if stale (must-revalidate).

Known limitations

Only the Loginapp module provides the JWKS endpoint described here.

Further information and links

Internal links: