Engineering Platform › Shared module · See it on the architecture map

Login Security (Auth Kit)

Every login screen needs to solve two problems safely: "is this the right password?" and "does this visitor still get to be logged in?" This package answers just those two problems, correctly, so no app has to reinvent them - it doesn't try to be a whole login system. Pulled out of GetSeen's own working login code so a second app could reuse the real logic instead of rewriting it from scratch. It stays deliberately small: it doesn't touch a database, doesn't manage cookies, doesn't decide how long you stay logged in - each app still handles that part itself.

Why it matters
Password hashing and session tokens are the two parts of a login that are easy to get subtly wrong and catastrophic when you do. They should be written once, correctly, and never re-implemented per application.
What I designed
A deliberately small package - four functions, two jobs - built on the same framework-independent primitives Flask's own login uses, so apps on different foundations can share it without pretending their frameworks match.
Used by
GetSeen. Tourney and Runway each have a stated reason for not using it - see below.
2 jobs, nothing else
check a password safely, and issue/verify a signed "you're logged in" token
1 live caller
GetSeen's real login runs on it
2 apps that skip it, for good reasons
Tourney and Runway don't use it, and each has a stated reason why - see below

What it actually does, in plain terms

There are only four functions in the whole package, and each one maps to a plain-English question. "Turn this password into something safe to store" and "does this password match what I stored?" handle the first problem - a site should never save a user's actual password, only a scrambled, one-way version of it (a "hash") that can be checked but not reversed. "Give this logged-in user a signed pass" and "is this pass still valid?" handle the second - a signed token is a small piece of data that proves who you are without the app needing to check a database on every single click, and the "signed" part means nobody can forge one without knowing a secret key only the app has.

That's the entire job. It doesn't decide where that token gets stored (a cookie, a header - the app's choice) or how long someone stays logged in (also the app's choice). It just does the two risky, easy-to-get-wrong parts correctly, once.

from auth_kit import hash_password, verify_password, sign_token, read_token

h = hash_password("correct-horse")
verify_password("correct-horse", h)          # True

token = sign_token(secret, {"username": "pete"})
read_token(secret, token, max_age_seconds=2592000)   # {"username": "pete"} or None

Where it runs, and where it honestly doesn't

GetSeen's real, live login runs on this package - not a demo, the actual system a real user's account security depends on. That's the adoption that actually matters: a package that was pulled out of one app but never actually used by anything else would just be a nice idea, not proven.

Tourney and Runway don't use it, and neither is an oversight. Tourney's login already works on a well-established library (Werkzeug's own security tools - the same kind of tool this package wraps), live and in real use, so it wasn't worth the risk of migrating something that already works correctly. Runway has no login at all, by design - it's a tool meant to run on one household's own computer, with no accounts to protect in the first place.