Scan your JWKS
Your entire authentication layer trusts the keys in one JSON document. PQLens fetches a JWKS (or OIDC key set) and classifies every signing key in it, so the token layer is in your inventory too.
pqlens scan jwks https://auth.example.com/.well-known/jwks.json
How it works
- Find your JWKS URL — for OIDC providers it is advertised in
/.well-known/openid-configuration. - Run
pqlens scan jwksagainst it; the document is fetched directly from your machine. - Each key is classified by type and size: RSA and EC signing keys are quantum-vulnerable; undersized RSA is broken.
- The findings join the inventory alongside your TLS, SSH and certificate surfaces.
Why the token layer is worth a row in the inventory
JWTs are signatures, and signatures age badly: a token that must remain verifiable, or an identity provider key that rotates yearly, is exactly the kind of long-lived asymmetric crypto post-quantum planning is about. Most orgs have never once looked at what is actually in their JWKS — it is a thirty-second scan.
Works on any JWKS, not just yours
The endpoint is public by design, so you can inventory the identity providers you depend on as well as the ones you operate — useful when a vendor questionnaire asks about third-party cryptography.
Frequently asked questions
Where do I find my JWKS URL?
For OIDC providers, fetch /.well-known/openid-configuration and use its jwks_uri value. Many stacks serve it directly at /.well-known/jwks.json.
Does this need credentials?
No. A JWKS is the public half of the signing keys and is served openly by design. PQLens fetches it directly from your machine.
What does a quantum-vulnerable JWKS key mean in practice?
The same as everywhere else: fine against classical attackers today, and a line in your migration plan rather than an emergency. Short-lived tokens age off quickly; the provider keys themselves are the asset to track.