What Flask-Login Solves
Flask-Login is an extension that manages the common, repetitive parts of user session handling — remembering which user is logged in across requests, protecting views that require authentication, and handling 'remember me' cookies — without dictating how you store users or verify passwords, which remain your application's responsibility. It centers on a LoginManager instance attached to the app, a user_loader callback that reconstructs a user object from an ID stored in the session, and helper functions like login_user(), logout_user(), and current_user that make authenticated state easy to access anywhere in the request.
Cricket analogy: Flask-Login is like a stadium's centralized accreditation system that handles gate scanning and access logs uniformly across every entrance, while each individual broadcaster still manages its own camera crew credentials — the extension standardizes the 'who's allowed in' mechanism without dictating how you vet each person.
UserMixin and the user_loader Callback
Flask-Login expects a user object with is_authenticated, is_active, is_anonymous properties and a get_id() method; rather than implementing these manually, most apps have their User model inherit from flask_login.UserMixin, which provides sensible defaults for all four. The LoginManager's @login_manager.user_loader-decorated function receives the string ID stored in the session on every request and must return the corresponding user object (or None if it no longer exists), which Flask-Login then exposes as the current_user proxy for that request.
Cricket analogy: UserMixin is like adopting the standard ICC playing conditions template instead of drafting your own rules from scratch for every match — it gives you sensible defaults (over limits, DRS rules) that you only override when your tournament needs something different.
from flask import Flask, request, jsonify
from flask_login import (
LoginManager, UserMixin, login_user, logout_user,
login_required, current_user
)
from werkzeug.security import generate_password_hash, check_password_hash
app = Flask(__name__)
app.secret_key = 'set-via-environment-variable-in-production'
login_manager = LoginManager()
login_manager.init_app(app)
login_manager.login_view = 'login'
class User(UserMixin):
def __init__(self, id, username, password_hash):
self.id = id
self.username = username
self.password_hash = password_hash
users_by_id = {
'1': User('1', 'ada', generate_password_hash('secret123'))
}
@login_manager.user_loader
def load_user(user_id):
return users_by_id.get(user_id)
@app.route('/login', methods=['POST'])
def login():
data = request.get_json(silent=True) or {}
user = next((u for u in users_by_id.values()
if u.username == data.get('username')), None)
if user is None or not check_password_hash(user.password_hash, data.get('password', '')):
return jsonify({'error': 'Invalid credentials'}), 401
login_user(user)
return jsonify({'message': f'Logged in as {user.username}'}), 200
@app.route('/logout', methods=['POST'])
@login_required
def logout():
logout_user()
return jsonify({'message': 'Logged out'}), 200
@app.route('/dashboard')
@login_required
def dashboard():
return jsonify({'user': current_user.username}), 200Protecting Routes with login_required
Decorating a view with @login_required causes Flask-Login to check current_user.is_authenticated before running the view; if the check fails, it redirects (for HTML apps) to the URL configured as login_manager.login_view, or, for pure JSON APIs, it's common to set login_manager.unauthorized_handler to return a 401 JSON response instead of a redirect. Within any protected view, current_user behaves like a normal user instance — you can read current_user.username or query relationships — because Flask-Login resolves it once per request via the user_loader callback and caches it on the request context.
Cricket analogy: login_required is like a boundary rope steward checking for a valid pass before letting anyone step onto the outfield; no pass means immediate redirection to the ticket office, just as an unauthenticated request gets redirected to login_view.
For JSON APIs, override the default redirect behavior by setting login_manager.unauthorized_handler(callback) to return jsonify({'error': 'Unauthorized'}), 401 instead of Flask-Login's default HTML redirect, which is designed for traditional server-rendered login flows.
Remember-Me Cookies and Session Lifetime
Calling login_user(user, remember=True) issues a separate, longer-lived signed cookie (distinct from the session cookie) that lets Flask-Login re-authenticate a returning visitor even after their session cookie has expired, controlled by app.config['REMEMBER_COOKIE_DURATION']. This is different from simply extending the session lifetime with app.permanent_session_lifetime, because the remember cookie specifically re-establishes current_user on a new request without requiring the full login form to be resubmitted, while still going through the user_loader to confirm the account still exists and is active.
Cricket analogy: A remember-me cookie is like a multi-day Test match ground pass that gets you back in each morning without re-registering at the gate, distinct from a single day's match ticket (the session cookie) that expires when play ends.
Remember-me cookies extend how long an attacker who steals a device or cookie can impersonate a user, so pair remember=True with reasonable REMEMBER_COOKIE_DURATION values, HTTPS-only cookies (REMEMBER_COOKIE_SECURE=True), and a way for users to revoke sessions (e.g. rotating a per-user token checked in user_loader).
- Flask-Login manages session-based user tracking, route protection, and remember-me cookies without dictating your user storage or password verification.
- UserMixin supplies default is_authenticated, is_active, is_anonymous, and get_id() implementations for your User model.
- The @login_manager.user_loader callback reconstructs a user object from the ID stored in the session on every request.
- login_user() and logout_user() establish and clear the authenticated session; current_user exposes the resolved user in views and templates.
- @login_required protects a view, redirecting to login_view (or invoking a custom unauthorized_handler for APIs) when unauthenticated.
- login_user(user, remember=True) issues a separate longer-lived cookie for persistent login beyond the normal session lifetime.
- Remember-me cookies increase the impact of a stolen device or cookie, so pair them with secure cookie flags and revocation strategies.
Practice what you learned
1. What is the purpose of the @login_manager.user_loader callback?
2. What does inheriting from flask_login.UserMixin provide?
3. What happens when an unauthenticated request hits a view decorated with @login_required (default configuration)?
4. What is the effect of calling login_user(user, remember=True)?
5. Why is overriding unauthorized_handler often necessary for a JSON API built with Flask-Login?
Was this page helpful?
You May Also Like
User Authentication in Flask
Understand the core building blocks of authenticating users in Flask: password hashing, login forms, and session-backed identity.
Session Management in Flask
Understand how Flask's signed cookie-based sessions work, their limitations, and how to configure them securely.
Building REST APIs with Flask
Learn how to design and implement RESTful APIs in Flask using route decorators, HTTP verbs, and JSON responses.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics