Flask-Login

Flask-Login handles the parts of user authentication that Flask itself doesn’t provide an opinion on: tracking a user’s logged-in state across requests, storing that state in the session, protecting views that require login, and handling “remember me” cookies. It deliberately does not implement password hashing, user storage, or OAuth flows itself — instead it expects you to provide a User class (via a mixin) and a user_loader callback, and it wires up the session-tracking plumbing around whatever authentication backend you choose.

This narrow scope is why it’s become the de facto standard for session-based auth in Flask apps: it’s small, focused, and composes cleanly with any credential-checking logic (a database lookup, an OAuth callback, LDAP, etc.) without dictating your data model. It’s maintained under Max Countryman’s GitHub account with a long history dating back to its original author Matthew Frazier, and remains a required dependency in most Flask tutorials and starter kits that need logged-in users.

What You Get

• A LoginManager extension object that hooks into Flask’s request lifecycle to load the current user from the session on every request
• UserMixin providing default implementations of the properties Flask-Login expects (is_authenticated, is_active, get_id)
• @login_required view decorator that redirects unauthenticated requests to a configurable login view
• current_user proxy giving templates and views access to the logged-in user (or an anonymous user object) without passing it explicitly
• “Remember me” cookie support for persisting login across browser sessions, with configurable duration and secure cookie options
• Signals (via blinker) for login/logout events that other extensions or app code can subscribe to

Common Use Cases

• Adding session-based login/logout to a Flask app backed by a SQL database of users
• Protecting admin or account-settings views so only authenticated users can reach them
• Implementing “remember me” functionality so users stay logged in across browser restarts
• Integrating with Flask-SQLAlchemy or Flask-Security-style extensions that need a pluggable session/auth layer
• Exposing the logged-in user to Jinja2 templates via current_user for conditional rendering (e.g. showing a logout link)

Under The Hood

Architecture - The extension centers on login_manager.py (LoginManager, ~460 lines), which registers Flask request hooks (before_request/context processors) to load the user identified in the session via a developer-supplied user_loader callback, and exposes current_user as a Werkzeug local proxy. utils.py implements the functional API (login_user, logout_user, login_required, fresh_login_required) built on top of the manager, while mixins.py supplies default UserMixin/AnonymousUserMixin base classes so applications don’t have to hand-implement the small interface Flask-Login expects. Tech Stack - A thin extension over Flask (>=2.3) and Werkzeug (>=2.3.2), using Python’s standard session cookie signing (via Flask’s itsdangerous-backed sessions) rather than its own crypto, and blinker-based signals for the login/logout event hooks; packaged with flit_core as a minimal single-purpose sdist/wheel. Code Quality - The tests/test_login.py suite is the primary test surface, exercising login/logout flows, remember-cookie behavior, and view protection against a small Flask test app fixture; the codebase itself is compact (~1,100 lines across src/flask_login), keeping the surface area easy to audit line-by-line. API Design - The public API is intentionally minimal and Flask-idiomatic: a single LoginManager to configure, a handful of decorators and functions (login_required, login_user, logout_user), and one mixin to inherit from, which is why it integrates into nearly any Flask app’s user model with only a few lines of glue code.