When anyone can read a blog, but only known users should post or comment, the application needs to identify who is making each request. Authentication is the process of checking that a user is who they claim to be; it establishes identity before the application decides which features to expose. section 8.0 section 8.2
A practical email-and-password login follows a short workflow:
- A GET request displays the login form; submitting it sends a POST request to the login endpoint. section 8.2.1
- The application looks up the user by email and checks the supplied password against the stored password hash. Never store plain-text passwords. section 8.2.1
- After a successful login, the application can return the user to the home page or their original destination. Session management lets later requests recognize the user, while protected endpoints restrict access to authenticated users. section 8.2.1 section 8.2
Authentication answers “Who are you?” Authorization answers “What may you do?” A logged-in identity can be paired with roles to control who creates, edits, or activates content and who may visit particular routes. Email confirmation helps verify a claimed address; password resets support users who cannot log in. section 8.5 section 9.9
Make login visible throughout the application
In a shared navigation template, a Jinja macro displays Login when the current user is unauthenticated and Logout when they are authenticated. The menu then reflects the same state used to control access. section 9.1
Flask extensions can handle login sessions, password hashing, forms, and user storage, but a working login is not the last word in security. Tighter requirements may call for two-factor authentication or a third-party authentication service. section 9.8 section 8.2.1
