What it is
Identity providers do the heavy lifting — auth flows, MFA, social login, account merging, JWT issuance — and they do it well. The defaults are tuned for time-to-launch rather than security, which is reasonable for a developer tool but matters once your app sees production traffic. Clerk and Auth0 are the modern leaders, both ship a public configuration discovery surface that's perfectly fine in isolation and quietly informative when combined with other recon. Permissive redirect URI allowlists, exposed tenant discovery, social-provider lists that reveal your employee SSO setup — each is a small leak; together they help target the social engineering that follows.
How it happens
Both providers publish tenant configuration to the browser. Clerk's frontend API returns the instance's client-side settings: enabled sign-in methods, social providers (Google, GitHub, etc.), redirect URLs, organization features, and branding. Auth0's OpenID Connect discovery document and JSON Web Key Set are required by the protocol, and they reveal the issuer URL, supported algorithms, and the tenant's public keys. Beyond discovery, common configuration mistakes include overly broad `redirect_uri` allowlists (wildcards or partial matches), unused social providers left enabled, and JWT signing keys with weak rotation policies.
Common variants
Permissive redirect URI
Allowlist accepts wildcards or partial matches (`https://*.yourdomain.com/*`). Attacker registers a subdomain that matches and harvests authorization codes through their own callback.
Unused social provider enabled
GitHub login enabled but nobody uses it; remains a vector for account hijack via social-account takeover (attacker compromises victim's GitHub, signs in to your app via SSO).
Tenant discovery for spear-phishing setup
Public discovery endpoint reveals branding, organization name, configured providers. Attacker crafts a phishing page that exactly mirrors the real SSO flow.
Long-lived JWT signing keys
Without rotation, a single JWKS compromise (insider, supply chain) compromises every token issued for the lifetime of the key.
What an attacker gets
Social engineering leverage dominates: knowing every redirect URI helps craft pixel-perfect phishing pages; knowing the tenant's IdP list helps spear-phish employees through familiar-looking SSO flows. Direct impact when redirect URI allowlists are too permissive — attacker harvests authorization codes via a controlled subdomain. Account takeover via unused social providers when an employee's external account gets compromised. JWT-issuer compromise is rare but devastating: every token signed with the leaked key is forgeable until rotation.
// what fixvibe reports
What FixVibe reports
Runs on every URL scan: paste your app's URL, nothing to install. The free preview shows your top findings; Hobby and above unlock the full report. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Restrict allowed redirect URIs to exact matches. Audit your Auth0 application's 'Allowed Callback URLs' and 'Allowed Logout URLs' lists; the same for Clerk's redirect URL configuration. Disable social providers your users aren't actually using — every enabled provider is an additional account-takeover surface. Rotate JWT signing keys on a schedule (annual is fine for low-risk apps; quarterly for high-risk); both Clerk and Auth0 support overlap-windows so existing tokens remain valid during rotation. For Auth0, configure tenant-level rate limits on auth endpoints. For Clerk, audit the publishable-key bindings and tenant settings — the dashboard surfaces drift from recommended baseline. As a defense-in-depth layer, monitor for anomalous auth events (mass signups, cross-region logins) — both providers offer this telemetry.