# Flask-Security bundles authentication for Flask and stops being the abandoned one

> Flask-Security is the Pallets-Eco continuation of Flask-Security-Too, a batteries-included security layer for Flask that pulls in login, roles, two-factor, WebAuthn, social login and unified signin. The release line is busy, the dependency set is opinionated, and the PyPI name is a decision you have to make once.

**pallets-eco/flask-security** — Quick and simple security for Flask applications

- Repository: https://github.com/pallets-eco/flask-security
- Stars: 697 · Forks: 172
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pallets-eco-flask-security

## Why the project renamed itself twice

The history of this package matters more than usual, because the name you install is not the name the project started as. The notes on the repository explain that as of 2024-07-30 the independent fork Flask-Security-Too replaced the archived Flask-Security repo, which was renamed Flask-Security-3.0. Flask-Security-Too itself was a fork from the 3.0.0 version of the original project, by Matt Wright. The current repository is published at PyPI under both names, Flask-Security and Flask-Security-Too, and the documentation asks you to consider changing your requirements file to point at flask-security. The reason for the fork was that the original repository was archived, and the maintainers here are Chris Wagner and Matt Wright, with the package maintained under the Pallets Community Ecosystem, which is the arrangement Pallets uses for community-maintained projects related to Flask. The practical consequence for a team starting fresh is simple: install flask-security, because that is the name the project wants you on and the one its releases are published under. For a team with an existing Flask-Security-Too pin, the upgrade path is a rename in one file plus a version bump, and the repository carries both a pyproject.toml and a pyproject-too.toml so the two names can be built from the same source.

## The dependency list is the design statement

The package does not try to be a small set of hooks into Flask. It pulls in a stack and treats that stack as the point. Flask-Login handles the session side, Flask-Principal handles roles and permissions, Flask-WTF handles the form layer, libpass handles password hashing, wtforms is there for form-level errors, email-validator validates addresses, and markupsafe is a transitive requirement listed explicitly. The goal section says this directly: be more opinionated and batteries included by reducing reliance on abandoned projects and bundling in support for common use cases. That is the trade, stated up front. You get a complete, working authentication stack, including the security decisions you did not want to make, and you inherit the opinion of whoever made them. The alternative is assembling the same pieces yourself, which is what many teams do and what the project is explicitly trying to make unnecessary. The dependency set also carries constraints worth reading before you install, with Flask at 3.1.1 or newer, Flask-Login at 0.6.3, Flask-Principal at 0.4.0, Flask-WTF at 1.1.2, email-validator at 2.3.0, libpass at 1.9.3 and wtforms at 3.2.1, and the package requires Python 3.11 or newer.

## One install command, and the release cadence behind it

Installation is a single pip command, with the -U flag in the project's own instructions.

```bash
    pip install -U Flask-Security
```

Beyond that, the interesting operational detail is the release rhythm. The recent history is dense: 5.9.0 on 2026-09-24, then 5.9.1 and 5.8.3 both dated 2026-09-30, with the last push to the repository on 2026-10-17. A patch release and a minor release landing on the same day is the signature of a project with an active issue queue and a maintainer willing to ship quickly. The project also advertises the OWASP ASVS project as the guide for best practice and default configurations, which is a specific and checkable claim about where the defaults come from rather than a general statement about security. Two optional dependency groups are declared, babel for translations with babel at 2.17.0 and flask_babel at 4.0.0, and fsqla for the SQLAlchemy integration with flask_sqlalchemy at 3.1.1 and sqlalchemy at 2.0.41, and the examples directory shows those paths in use with fsqlalchemy1, oauth and unified_signin. The package is classified as Development Status :: 5 - Production/Stable and as OS Independent, with classifiers for CPython and PyPy.

## The feature list reads like a release history

The goals section doubles as a changelog of what the extension grew into, and reading it tells you which version introduced which capability. Support for Refresh Tokens is listed for 5.9, so that is the current line. Username recovery and changing username arrived in 5.6, changing email in 5.5, social login using authlib in 5.1, and WebAuthn with passkey support plus two-factor recovery codes in 5.0. First-class support for username as identity is credited to 4.1, while 4.0 brought a freshness decorator to ensure sensitive operations require new authentication, email normalization and validation, and two or multi-factor authentication supporting SMS, email and authenticator apps. A unified signin feature covering username, phone and passwordless is credited to 3.4, which is the version the fork was taken from. Two of these are worth pausing on if you are evaluating the package. The freshness decorator is a direct answer to session-riding and stale-session risk on sensitive operations, and it is a decorator you have to remember to apply. Unified signin is a large surface, and it is the feature most likely to need configuration work specific to your deployment, particularly the phone and passwordless paths.

## Where the project is opinionated against you

Three trade-offs are visible in the repository itself rather than in marketing. The first is the optional dependency model. The base install is authentication and forms, and the database integration sits in the fsqla extra, so a SQLAlchemy application installs the fsqla group explicitly rather than getting it by default. The second is that the project aims to follow the Pallets lead on supported versions, documentation standards and any other guidelines for extensions, which is a good discipline but also means your version matrix is decided partly by a group you do not sit in. The third is the license. The project is MIT, with the license text in LICENSE.txt and the classifier License :: OSI Approved :: MIT License, and it is one of the most permissive choices available, so if you intend to build a product on top of it there is no copyleft obligation to design around. The cost of MIT here is that you get the code with no warranty of any kind, and the maintenance notes are explicit that this is a community project maintained through the Pallets-Eco arrangement rather than a commercial product with support contracts.

## Where Flask-Security is the wrong choice

There are three situations where this package costs you more than it saves. The first is an application that already has an identity layer. If your users authenticate through an existing provider and you store your own user records, adding Flask-Security means reconciling two models of identity rather than removing work. The second is a case where you need to deviate from the defaults in a way the extension points do not cover. The stated goal is that the library is opinionated and batteries included, and an opinionated library is a good fit exactly until you need it to be unopinionated. The web interface, the templates and the model assumptions are all part of the package, and a custom login flow is where you will feel that. The third is a project that cannot accept a dependency stack this wide. Flask-Login, Flask-Principal, Flask-WTF, wtforms, libpass, email-validator and markupsafe, with lower bounds that keep moving, is a lot of surface to own and to keep current. The project answers this by aiming at OWASP ASVS defaults, which is the right answer for a team that wants a defensible baseline, and the wrong answer for a team that has already made those decisions. There is also the naming transition to plan for, since your requirements file, your lock file and your CI images all have to agree on which of the two PyPI names you depend on.

## Conclusion

Adopt Flask-Security if you want the whole authentication surface of a Flask application decided for you in one dependency, and you accept that the defaults come from OWASP ASVS rather than from your own threat model. Skip it if your application already has an identity system, or if you need a custom login flow the extension points do not cover, since the package is explicitly more opinionated than a toolkit. Before you pin a version, check whether your requirements file should point at flask-security or flask-security-too, because the project is published under both names and the maintenance notes ask you to move to flask-security.

## FAQ

### How do I install Flask-Security?

The project documents a single pip command, pip install -U Flask-Security, and the package requires Python 3.11 or newer with Flask 3.1.1 or newer. Optional extras are available for translations through the babel group and for SQLAlchemy through the fsqla group.

### What is the difference between Flask-Security and Flask-Security-Too?

Flask-Security-Too was an independent fork taken from version 3.0.0 of the original Flask-Security project and replaced the archived original as of 2024-07-30. The current repository publishes under both PyPI names, and the notes ask you to point your requirements file at flask-security.

### Which authentication features does Flask-Security support?

The feature list covers two-factor and multi-factor authentication over SMS, email and authenticator apps, WebAuthn and passkeys, two-factor recovery codes, social login through authlib, refresh tokens, username recovery and username change, email change, email normalization and validation, and a unified signin covering username, phone and passwordless flows.

### What licence is Flask-Security released under?

MIT, with the license text in LICENSE.txt in the repository root and the classifier License :: OSI Approved :: MIT License in the package metadata. The project is part of the Pallets Community Ecosystem, where Pallets-Eco enables community maintenance of related projects.

## Sources

- [Issues](https://github.com/pallets-eco/flask-security/issues)
- [License: MIT](https://github.com/pallets-eco/flask-security/blob/main/LICENSE)
- [pallets-eco/flask-security on GitHub](https://github.com/pallets-eco/flask-security)
- [README](https://github.com/pallets-eco/flask-security/blob/main/README.md)
- [Releases](https://github.com/pallets-eco/flask-security/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pallets-eco-flask-security