Ways of serving a JWKS Endpoints
There are several viable solutions and approaches you can use to serve a JWKS endpoint, ranging from leveraging managed identity providers to implementing it manually within your application.
Summary of Solutions
Solution | Pros | Cons |
---|---|---|
Managed Identity Provider | Most straightforward to implement, automatic key rotation, high security, and built-in scalability. | Less control over the process, resulting in vendor lock-in. |
Self-Hosted Application | Complete control over key generation and rotation; no vendor lock-in. | Requires manual implementation; higher security responsibility; needs to handle key storage and rotation securely. |
API Gateway | Centralises key validation; offloads work from backend services, making it suitable for microservices. | Requires infrastructure setup (e.g., Lambda); can add complexity. |
Regardless of the method you choose, remember that the endpoint must be publicly accessible and serve only the public keys. The private keys must be stored securely and never exposed.
Using a Managed Identity Provider
The most secure and convenient solution is to use a dedicated Identity Provider (IdP) service that handles this automatically. These services manage key generation, rotation, and endpoint serving for you, reducing the security burden.
- Auth0: As a tenant in Auth0, your JWKS endpoint is automatically generated and hosted for you. The URL follows a predictable pattern, such as
https://{yourDomain}/.well-known/jwks.json
. You configure your clients to retrieve keys from this endpoint to verify JWTs. - AWS Cognito: If you use AWS Cognito user pools, a JWKS endpoint is provided out of the box for each pool. The endpoint URL is
https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json
. This endpoint allows other applications to verify JWTs issued by your Cognito user pool. - Keycloak: Keycloak, an open-source identity and access management solution, also automatically serves a JWKS endpoint for each realm. The public keys are typically available at
https://[your-keycloak-instance]/realms/{realm-name}/protocol/openid-connect/certs
.
Implementing a JWKS Endpoint in Your Application
If you are not using a managed IdP and want to self-host, you can implement the JWKS endpoint directly within your application's backend.
- Using a Web Framework: Most modern web frameworks make it easy to create an API endpoint. You would create a route, for example,
/jwks.json
, that returns a JSON object containing your public keys. - Programming Libraries: You should use a library to handle the cryptographic operations and JWK formatting. For example:
- Node.js: Libraries like
node-jose
orjose
can be used to generate JWK public/private key pairs and format them correctly for the JWKS endpoint. - Python: Libraries like
python-jose
provide similar functionalities to handle JWK creation and formatting. - Java: You can use the
java-jwt
library or the JOSE suite libraries to manage keys and build the JWKS response.
- Node.js: Libraries like
Deploying a JWKS Endpoint with an API Gateway
For a microservices architecture or to offload key management, you can use an API Gateway to serve the JWKS.
- AWS API Gatewayauthoriser: You can configure AWS API Gateway to use a custom authoriser, which can then use a JWKS endpoint to validate incoming JWTs. While the JWKS endpoint itself could be a simple AWS Lambda function, the API Gateway centralises the validation logic.
- Nginx/Reverse Proxies: You can also use a reverse proxy like Nginx to serve a static JWKS file or proxy requests to a backend service that generates the JWKS content. Reverse proxies are a typical pattern for production environments to improve performance and security.
Updated about 2 months ago