# Authentication ## Registration This is how a new user registers himself in `authfs`, after which he can open sessions. - Client `GET`s `shop./register.html` - Client enters username and password, `POST`s form to `api./register` - `buthd` registers user in `authfs` - Creates `/users//` - If it already exists, the username is taken; return error to client - Writes password to `/users//passwd` - `authfs` ingests and hashes the password. - If successful, client can now login to obtain a session ## Login This is how a client authenticates itself and creates a _session_. A session gives the client a shopping cart and access to the checkout. - Client `GET`s `shop./login.html`. - Client enters username and password. - JS script running in client generates a 256-bit session ID and injects it into the login form. - Client `POST`s the login form to `api./login` - `buthd` writes the password to `/users//login` in `authfs` - If `/users//` doesn't exist, the username is invalid; fail the login - `buthd` reads from `/users//login` - If the password was correct, `authfs` returns a session ID corresponding to `/sessions// - Otherwise if the password was wrong, `authfs` returns `Rerror`. `buthd` fails the login, returning an error to the client - `buthd` returns a session cookie containing the session ID to the client (with proper security params: HttpOnly etc.) - Client includes the session cookie in subsequent requests, giving it elevated privileges. On the client, session is a _session cookie_ (no expiry date). On the server, it should expire after `lastseen+t`. `authfs` periodically sweeps the sessions and removes old ones. `authfs` updates a sessions's last-seen time whenever it gets a request on `/sessions//*`. Generate the session id on the client side to take advantage of the abundance of entropy there compared to on the server. ## Logout This is how a client destroys an active session on the server. - Client clicks Logout button - htmx `POST`s to `api./logout`, includes the session cookie in the request - `buthd reads the session ID from the cookie - `buthd` removes `/sessions/` on `authfs` - `buthd` returns a response header telling the client browser to destroy the session cookie. ## TODO - Allow the user to register an email for password recovery? - Document changing password: buthd writes to `/users//passwd` ## Implementation notes Don't leave 9p connections laying around. Open a new one for each http request as required. This is to avoid attacks like the following. Suppose buthd has a single connection to authfs that it uses for every http connection. Alice (the attacker) and Bob are both trying to login as `bob`. Alice's connection writes a junk password to `/users/bob/login`. Bob's connection writes the correct password. Alice's connection reads `login`, obtaining the session ID, as does Bob's connection. Now Alice has Bob's session ID and can act as Bob. This is bad.