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.
How it works
- Find your JWKS URL — for OIDC providers it is advertised in
/.well-known/openid-configuration. - Open the JWKS tab and paste it in — your browser fetches the document directly; only that URL is contacted.
- Each key is classified by type and size: RSA and EC signing keys are quantum-vulnerable; undersized RSA is broken.
- Sync the findings to join your TLS, SSH and certificate surfaces in one inventory.
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 takes about thirty seconds.
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. If the endpoint blocks cross-origin fetches, drop the JSON file into the tab instead.
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. Your browser fetches it directly.
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.