> 2. The password is sent repeatedly, for each request. (Larger attack window) We, for example, have a different web service for authentication. That's literal

> 2. The password is sent repeatedly, for each request. (Larger attack window) We, for example, have a different web service for authentication. That's literally all it does, it checks username/passwords, generates a token, returns a cookie, and then is never used again for that user's life cycle. This allows us to set database/table permissions such that a compromise in any other part of the web site cannot trivially be leveraged into a credentials theft (even hashed credentials), and are able to deploy the authentication web service in a minimal state. That is harder with basic auth, you'd likely need a request filter in front of every incoming request (inc. error pages). This means that every web server/web app instance you deploy needs access to user credentials. Plus it gives you the flexibility to easily expire a single user or ALL user's active sessions just by either removing their token from a table, or rotating the encryption key(s) that are used to protect your authentication cookies. I'd offer a few more reasons: - No great way to offer forgotten password/help (or alternative workflows, such as "create an account"). - Focus stealing login dialogs that hold the user hostage (& bad browser implementations in general). - Dialogs cannot be styled to the site/page - Error workflow is clunky, no in-line errors/warnings e.g. "Your username should be an email address." - Worse password manager support