Free · spec-cited · reads only public metadata
SSL Labs for your Identity Provider
Paste an OIDC/OAuth issuer URL and get an instant, shareable security-posture grade — built entirely from the provider’s published discovery metadata. Every finding cites the RFC.
Fetch
Only the two well-known discovery paths + the JWKS — over HTTPS, never private ranges.
Grade
23 spec-cited checks (keys, algs, PKCE, flows, mix-up, PAR…). Fixed, versioned rubric.
Share
An immutable /scan/… permalink you can send to your team or auditor.
See the payoff first
A worked example of what a report looks like.
Scanned issuer
https://issuer.example.com
Notable gaps worth addressing.
illustrative · ruleset 2026.07.3
- FLOW-02
PKCE S256 not supported
Failcode_challenge_methods_supported advertises “plain” only; the Security BCP requires S256.
RFC 9700 §2.1.1
- ALG-02
Symmetric (HMAC) signing advertised
WarningHS256 shares the verification secret with every client and invites key-confusion.
RFC 8725 §3.5
- KEY-03
Only one signing key published
WarningA single JWKS key means rotation cannot overlap and will break in-flight tokens.
RFC 7517
- MIX-01
Mix-up defense (iss parameter) supported
BonusAuthorization responses carry the “iss” parameter, defending against IdP mix-up.
RFC 9207
- PAR-01
Pushed Authorization Requests supported
BonusA PAR endpoint lets clients send authorization parameters over a secure back channel.
RFC 9126
- HYG-01
JWKS has no cache-control
InfoThe JWKS response lacks a max-age; clients may over-fetch or cache keys unpredictably.
RFC 7517
Every real finding links straight to the cited RFC/BCP section. Values above are made up to illustrate the format.
What we check
A fixed, versioned rubric of 23 checks across six families — grounded in the OAuth/OIDC RFCs, the Security BCP, and NIST key guidance. No opinions, no FUD: every finding cites its spec.
Discovery integrity
4 checks- Discovery document reachable over HTTPS and non-empty
- issuer matches the requested URL exactly (anti-spoofing, §3.3)
- Every OAuth/OIDC endpoint served over HTTPS — plaintext is an automatic F
RFC 8414
Signing keys & JWKS health
7 checks- JWKS resolves and holds at least one usable signing key
- RSA ≥ 2048 bits; only approved EC (P-256/384/521) and OKP (Ed25519/448) curves
- Rotation overlap, unique kid, and x5c certificate-expiry checks
RFC 7517 · NIST SP 800-57/186 · RFC 5280
Token algorithms
4 checks- The “none” algorithm is never advertised — an automatic F if it is
- Symmetric HMAC signing flagged for key-confusion risk
- RS256 advertised as required; modern ES256/EdDSA earns credit
RFC 8725 · OIDC Discovery
Authorization flows & PKCE
3 checks- Deprecated implicit/hybrid front-channel token delivery is flagged
- PKCE S256 must be discoverable; a “plain”-only offering fails
- “plain” alongside S256 noted as a minor hygiene item
RFC 9700 · RFC 7636
Mix-up & request hardening
3 checks- iss authorization-response parameter (mix-up defense) credited
- Pushed Authorization Requests (PAR) support and enforcement credited
- Strong client auth (private_key_jwt / mTLS) credited
RFC 9207 · RFC 9126 · OIDC Core
Transport & hygiene
2 checks- JWKS cache-control sanity (missing or over-long max-age)
- Invalid, credentialed wildcard CORS on discovery/JWKS
RFC 7517 · RFC 8414
What an external scan cannot see
By design, oidcscan reads only public metadata. It cannot see token lifetimes, refresh-token rotation, consent policies, or per-client configuration. Judging those requires access to your tenant — that is what an IntegrAuth identity audit covers.
Free · continuous monitoring
A one-off scan is a snapshot. Postures drift.
Create an account, add the issuers you care about, and oidcscan re-scans them on a schedule — then emails you the moment something changes. No dashboards to babysit.
Schedule it
Pick hourly, daily, or weekly re-scans per issuer. A cron runs them for you.
Catch regressions
Alerts on grade changes, key rotation (kid added/removed), new fail/warn findings, and issuer downtime.
Never miss an expiry
Escalating heads-up when a signing certificate enters its 30-day window, then again if it actually lapses.
Frequently asked
Is it safe to scan my identity provider?
Yes. oidcscan fetches only the two public well-known discovery paths and the JWKS the provider already publishes — the exact URLs any OAuth client reads. It never touches private IP ranges, never sends credentials, and makes no authenticated calls. The scan is indistinguishable from a normal client startup.
Do I need an account?
No. Public scans are completely free and require no sign-up — paste an issuer, clear the bot check, and share the result. An account is only needed for continuous monitoring — scheduled re-scans and regression alerts — which is also free.
How fresh is a grade?
Each scan reflects the metadata at fetch time and is cached per issuer for about an hour. Every result records the exact ruleset version that produced it, so a permalink stays reproducible. Force a fresh scan any time with the “Re-scan” button on a report.
Are there rate limits?
Yes — the public scan endpoint is bot-protected with Cloudflare Turnstile and rate-limited per source. Hitting the limit returns a clean “please wait” message, not an error. Monitored issuers are re-scanned on their own schedule and don’t consume the public limit.
Can I share results?
Every scan gets an immutable /scan/… permalink you can send to your team or an auditor. It carries the grade, every finding, the spec citations, and the ruleset version — the page renders the same for anyone who opens it.
What can an external scan not see?
By design, only public metadata. It cannot judge token lifetimes, refresh-token rotation, consent policies, or per-client configuration — those need tenant access, which is what an IntegrAuth identity audit covers.
oidcscan
SSL Labs for your Identity Provider.