A self-hosted crawler that visits a website and tells you which identity and authentication platform it runs: Clerk, Auth0, Okta, Firebase, SuperTokens, Keycloak, WorkOS, Kinde, and about 20 others. It reports a provider only when it has real evidence, so it does not invent answers.
$ authdetect stripe.com
https://stripe.com
auth provider : Okta
social login : Google Identity Services
evidence:
- Okta (high) cookie: okta-oauth-state
login : https://dashboard.stripe.com/login
docs : https://stripe.com/docs
Built by Shivangi.
Most "tech stack detectors" match a page against a keyword list and call it a day. That approach reports Firebase because the word "firebase" appears once in a footer, and it invents a /login URL because almost every site has that path. The results look plausible and are wrong often enough to be useless.
This detector takes the opposite stance. A website's own route structure proves nothing, because every framework ships /login, /auth/signup, and /oauth2/authorize. Vendor identity comes only from things a vendor actually owns: network requests to vendor hostnames, cookies with vendor-specific names, response headers unique to a vendor, custom DOM elements from a vendor SDK. A provider is reported only when it has at least one of those definitive signals, or at least two independent suggestive ones. That single rule removes the entire class of "generic path leads to false positive" errors.
Twenty-five identity and sign-in providers across three categories:
Full identity platforms: Clerk, Auth0, Okta, Firebase Auth, Supabase Auth, AWS Cognito, Microsoft Entra / Azure AD B2C, WorkOS, Descope, Stytch, Frontegg, Kinde, Logto, SuperTokens, Keycloak, Ory, Zitadel, FusionAuth, Magic, Hanko, Authgear, NextAuth / Auth.js, Better Auth.
Social sign-in add-ons: Google Identity Services, Sign in with Apple.
Protocol fallback: generic OAuth/OIDC, reported only when no named vendor is found and the site clearly exposes an OpenID configuration.
Adding a provider is one dictionary entry in crawler/app.py. Each entry declares its hosts, cookies, headers, DOM tags, SDK package names, and provider-specific paths. Nothing else in the code needs to change, which makes this an easy repo to send a pull request to.
The crawler loads the homepage in a headless browser, then probes the common login and signup paths. While the pages load it records every network request hostname, every cookie name, every response header of interest, and any custom DOM elements and SDK names in the page source. That evidence is scored against the provider registry: definitive signals (vendor hostnames, cookies, headers, DOM tags) confirm a vendor outright, while weaker signals (SDK package names, provider-specific paths) only count when two or more agree. Discovered docs and API URLs are admitted only after the page is fetched and shown to have real documentation structure, which is what stops the tool from reporting URLs that don't exist.
You need Docker. That's it. No GPU, no API keys, no accounts.
git clone https://github.com/tink-shivi/auth-stack-detector.git
cd auth-stack-detector
docker compose up -d --buildThen ask it about any site with the bundled CLI:
./authdetect stripe.comauthdetect uses only the Python standard library, so there's nothing to install. Point it at more than one site at once, or add --json for machine-readable output:
./authdetect stripe.com vercel.com
./authdetect example.com --jsonIf you would rather call the API directly, it's a plain HTTP endpoint:
curl -X POST http://localhost:8005/inspect \
-H "Content-Type: application/json" \
-d '{"website": "example.com"}'Either way it returns the detected providers with the exact evidence for each, plus discovered URLs:
{
"website": "https://example.com",
"primary_auth": "Clerk",
"social_logins": ["Google Identity Services"],
"auth_candidates": [
{
"vendor": "Clerk",
"confidence": "high",
"definitive_signals": ["network host: clerk.example.com", "cookie: __client"],
"suggestive_signals": ["package: @clerk/nextjs"]
}
],
"login_urls": ["https://example.com/sign-in"],
"signup_urls": ["https://example.com/sign-up"],
"docs_urls": ["https://example.com/docs"],
"api_reference_urls": ["https://example.com/docs/api"]
}POST /inspect with { "website": "<domain>" } runs the full detection above.
POST /fetch_pages with { "urls": [...], "max_chars_per_page": 3000 } returns clean readable text from a list of pages, stripped of nav, scripts, and footers. It's here because the detector already carries the machinery for it, and it's handy when you want page text rather than raw HTML.
The first docker compose up --build pulls a Playwright browser image, so it's a few hundred megabytes and not instant. After that, detection takes a few seconds per site because a real browser actually loads the page. That cost is the reason the results are trustworthy instead of guessed.
The crawler does not read robots.txt. If you run it across many sites, rate-limit yourself and set a truthful user-agent (it's one line in crawler/app.py).
auth-stack-detector/
authdetect the command-line front end (zero dependencies)
crawler/
app.py the detector: provider registry + crawl + scoring
Dockerfile
docker-compose.yml one service, one command to run
This is one of a set of self-hosted tools:
- cleanfetch — the clean-text web fetcher, as a standalone package and CLI.
- local-ai-stack — an n8n + Ollama + SearXNG starter for running local AI workflows.
- self-hosted-lead-pipeline — a guide to combining these into a private lead-research pipeline.
MIT with an attribution requirement. See LICENSE.
You are free to use, modify, and ship this. The one condition beyond standard MIT: if you fork it or build on it, credit the original author, Shivangi, with a visible link back to this repository. If it saved you time, a star is appreciated too.