# 2FA Directory: the community-maintained list of sites that support two-factor authentication

> 2factorauth/twofactorauth is a data repository, not an app. It holds the entries behind 2fa.directory and exposes them through a free API, with Jest tests enforcing the format of every contribution.

**2factorauth/twofactorauth** — List of sites with two factor auth support which includes SMS, email, phone calls, hardware, and software.

- Repository: https://github.com/2factorauth/twofactorauth
- Website: https://2fa.directory
- Stars: 3,466 · Forks: 1,772
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/2factorauth-twofactorauth

## What 2factorauth/twofactorauth actually is

The name is misleading if you arrive from a search for a two-factor authentication library. This repository does not generate codes, does not store secrets and does not sit in a login flow. It is a directory: a structured list of websites and services and which second factors they accept, covering SMS, email, phone calls, hardware tokens and software apps according to the project description. The README frames the goal as helping consumers compare services by the security they offer, and calls the directory an indicator of a site's general security efforts.

The audience is therefore narrow and specific. Security researchers comparing providers, journalists checking a claim about a breach or a policy change, and developers who want to warn users that a service they are about to sign up for has no second factor. The data lives in the entries/ directory, and the site at 2fa.directory is the human-facing view of it. The frontend is a separate repository, 2factorauth/frontend, which the README links explicitly. If you want to change how the directory looks, this is the wrong repository.

## How entries, tests and the API fit together

The mechanism is a data pipeline with a test suite bolted on as the gate. Contributions are files under entries/, validated by schemas. The package.json lists ajv, ajv-errors and ajv-formats as runtime dependencies, which is consistent with JSON Schema validation of each entry, and glob for walking the directory tree. Jest runs the checks, and the scripts split them by concern: test:entries, test:domains, test:images, test:categories, test:regions, test:languages, test:urls and test:api. That split tells you what the maintainers consider breakable. A bad domain, a dead URL, a missing icon, a category that does not exist, a region string that is not recognised: each has its own test file.

The API is the consumption surface. The README discourages scraping the Git repository directly, warning that changes might break your program, and recommends the API instead. API access is free, but the README states that distributing the data requires attribution under the project's license. The api-generation test script suggests the API output is generated from the same entries, so the schema you see in the repository is close to the shape you get over HTTP. The README does not document rate limits, pagination or an uptime commitment, so treat those as unknown until you check the API documentation page it links to.

Algolia is involved on the search side. The optional dependency algoliasearch and the .env.example keys point at it, and the index name defaults to 2fa.directory. Search on the website is therefore a hosted index, not a query over the repository files.

## Installing the repository and running its checks

There is no installable package here and no server to start. The repository is a Node.js toolchain for validating and generating data, so the useful first run is the test suite. Clone the repository, then install dependencies with npm.

```bash
npm install
```

Running the full suite tells you whether the entries in your checkout are internally consistent. The README does not give a first-use walkthrough, so the scripts in package.json are the practical entry point.

```bash
npm test
```

If you only care about one class of problem, the split scripts are faster. This one checks the entry files themselves.

```bash
npm run test:entries
```

For anything touching search or API generation, copy the environment template and fill in the Algolia credentials. The keys are empty in the example file.

```bash
cp .env.example .env
```

The .env.example file defines ALGOLIA_APP_ID, ALGOLIA_API_KEY and ALGOLIA_INDEX_NAME, the last defaulting to 2fa.directory. Without those values, anything that talks to Algolia will not have credentials. The README does not state which scripts require them, so check before assuming a failure is a data problem rather than a missing key.

## Where the data model will frustrate you

The directory records support, not quality. An entry saying a service offers SMS as a second factor says nothing about whether that service also supports app-based codes, whether it allows recovery by email, or how it handles account lockout. If your use case needs that nuance, the schema is likely to be thinner than you want, and the repository will not tell you where the gaps are.

Coverage is another limit. This is a community-maintained list, and the README describes it as community-driven, which means entries exist because someone contributed them. A service missing from the directory is not evidence that it lacks two-factor authentication. Any tool that treats absence as a negative signal is drawing a conclusion the data does not support.

The images directory carries a separate constraint. The README states that images inside img/ are not covered by the repository's license and remain the property of their respective authors, used under fair use principles. If you are building a product that displays service logos, that sentence is the one to read carefully before shipping. The code is MIT, but the logos are not.

Finally, the README explicitly warns against scraping the Git repository, because changes might break your program. That is a maintenance warning as much as a technical one: the file layout is not a stable interface, and the API is the intended contract.

## How this differs from a 2FA library

The most common confusion around this project comes from its name. Libraries such as RobThree/TwoFactorAuth solve the opposite problem: they generate and verify TOTP codes inside your application, so your users can enrol a second factor. That is code you import. This repository is data you query. One answers "how do I implement two-factor authentication"; the other answers "which services already offer it".

The practical difference shows up in dependencies. A TOTP library ships as a package you add to your runtime, and its correctness matters at login time. This repository ships JSON entries and a Jest suite, and its correctness matters when you display or filter a list. You can consume the 2FA Directory API from a static site with no backend at all, which is not something you can say about an authentication library.

If you need both, they do not overlap. Use a library to protect your own users, and use this directory if you want to tell those users which other services they can move to.

## Maintenance, licensing and what a fork costs you

The repository is not archived, and the last push was on 2026-09-21, two days before the date of writing. That is a live project by any reasonable reading, though the release history is sparse: v4.0 in October 2021, v3.0 in September 2020, and v2.1 back in May 2017. Releases are not how this project ships. Entries change continuously; version tags mark structural milestones.

The practical upgrade cost for a consumer is low, because you should be calling the API rather than vendoring the entries. If you do vendor them, you inherit the schema and the validation rules, and a schema change becomes your problem. The test scripts exist precisely so that contributors catch those breaks before merge, but that protection applies to the repository, not to your copy of it.

Licensing needs care and is not a legal question this article can settle. The README says the code is distributed under the MIT license, with a copy in LICENSE.md, while the repository metadata carries NOASSERTION. The README also states that distributing the data requires attribution, and asks commercial users to consider sponsoring the project on GitHub because maintaining it incurs regular bills. Read LICENSE.md itself before you redistribute anything.

## Conclusion

Adopt it if you need a machine-readable list of which services support two-factor authentication and you are willing to attribute the data and, for commercial use, consider sponsoring the project. Do not adopt it if you want to add 2FA to your own application: this repository contains no authentication code, no TOTP implementation and no server. Before you build on it, read the license file and check what the API returns for the fields you depend on, since the README points developers at the API rather than the repository.

## FAQ

### Is 2factorauth/twofactorauth a library I can use to add two-factor authentication to my app?

No. It is a directory of websites and services that support two-factor authentication, plus the API that serves that list. It contains no code for generating or verifying authentication codes.

### Should I scrape the Git repository or use the 2FA Directory API?

The README discourages scraping the repository directly, warning that changes might break your program, and recommends the API instead. API access is free, but distributing the data requires attribution under the project's license.

### Can I use the service logos from the 2FA Directory in my own product?

The README states that images inside img/ are not subject to the repository's license and are owned by their respective authors, used under fair use principles. The MIT license covers the code, not those images.

### What does the 2FA Directory test suite check?

The scripts in package.json split validation into entries, domains, images, categories, regions, languages, urls and api-generation, all run through Jest. Each script targets one class of problem in the data.

## Sources

- [2factorauth/twofactorauth on GitHub](https://github.com/2factorauth/twofactorauth)
- [Issues](https://github.com/2factorauth/twofactorauth/issues)
- [Project website](https://2fa.directory)
- [README](https://github.com/2factorauth/twofactorauth/blob/master/README.md)
- [Releases](https://github.com/2factorauth/twofactorauth/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/2factorauth-twofactorauth