Scribd
Upload
9 views4 pages

Flask Auth Notes

The document outlines key learnings about authentication and authorization in Flask, focusing on Flask-Login for session-based authentication and JWT for stateless authentication. It highlights differences between the two methods, implementation observations, and the possibility of a hybrid approach. Additionally, it covers validation of third-party OAuth tokens, emphasizing the importance of verifying signatures and claims.

Uploaded by

inspirationalquotes2133
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views4 pages

Flask Auth Notes

The document outlines key learnings about authentication and authorization in Flask, focusing on Flask-Login for session-based authentication and JWT for stateless authentication. It highlights differences between the two methods, implementation observations, and the possibility of a hybrid approach. Additionally, it covers validation of third-party OAuth tokens, emphasizing the importance of verifying signatures and claims.

Uploaded by

inspirationalquotes2133
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Flask Authentication & Authorization: Summary of Key Learnings

---

1. Flask-Login Based Session Authentication

How it works:

- On login, login_user(user) stores user.id in session['_user_id']

- On future requests, Flask-Login reads the session and calls @login_manager.user_loader(user_id)

- That method reconstructs the user object (e.g., from DB or mocked)

- current_user is set from the returned object

Key notes:

- g._login_user is request-local and not shared between users

- If current_user is accessed and no _login_user exists, _load_user() is called

- No DB call happens during login unless you explicitly make one

- load_user() is only triggered if session contains _user_id

---

2. JWT-Based Authentication (Stateless)

How it works:

- After verifying credentials, backend creates a JWT:

create_access_token(identity=user.id)

- JWT is returned in response headers or JSON

- Frontend must store this token and send it in Authorization: Bearer <token> header
Validation:

- JWT is validated using signature (with secret key)

- Claims like exp, sub, aud are validated

- User is extracted from jwt_data['sub']

- To populate current_user, define:

@jwt.user_lookup_loader

def user_lookup_callback(jwt_header, jwt_data):

return User.get(jwt_data["sub"])

---

3. Session vs JWT: Key Differences

Feature | Flask-Login (Session) | JWT-Based (Token)

------------------------|------------------------|-------------------

Storage | Server-side (cookie) | Client-side

Stateless | No | Yes

Identity Load Hook | @user_loader | @user_lookup_loader

Token Transmission | Cookie | Header (Bearer)

Use case | Web apps | APIs/mobile

---

4. Observations from Implementation

- Redirect-based responses discard custom headers like access_token


- Use make_response(jsonify(...)) to preserve headers in JSON responses

- Can return JWT as a header or JSON field

- current_user.is_authenticated will be False before calling login_user() in a session flow

- In JWT flow, @jwt_required() must be used to access current_user

---

5. Hybrid Flow

- You can mix JWT and session by:

- Using @jwt_required() for APIs

- Using login_user() for web UI

- Always generating JWT alongside session

- Remember: Flask will not auto-load user from JWT without @jwt.user_lookup_loader

---

6. Validating 3rd Party OAuth (e.g., Google SSO)

- Google ID Token is a JWT that can be validated locally:

from google.oauth2 import id_token

id_token.verify_oauth2_token(token, Request(), CLIENT_ID)

- Google Access Token must be validated via:

GET https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=...

- Always verify:
- Signature

- aud (matches your client ID)

- exp, iss

---

Final Thoughts

- current_user works seamlessly in session flow, but needs setup in JWT-based APIs

- load_user() always takes user ID extracted from session['_user_id']

- Use @jwt.user_lookup_loader for JWT-based user resolution

- Hybrid models are possible but require clarity on flow boundaries

You might also like