== Why we like HTTP Basic Authentication in Apache so much Our web server of choice [[here https://support.cs.toronto.edu/]] is Apache, and when we need some sort of access control for it for people, our usual choice of method is [[HTTP Basic Authentication https://en.wikipedia.org/wiki/Basic_access_authentication]] (also [[MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication]]). This is an unusual choice these days; most people use much more sophisticated and user-friendlier schemes, usually based on cookies and login forms and so on. We persist with HTTP Basic Authentication in Apache despite this because, from our perspective, it has three great advantages. The first advantage is that it uses a username and a password that people already have, because we invariably reuse our existing Unix logins and passwords. This gets us out of more than making people remember (or note down) another login and password; it also means that we don't have to build and operate another account system (with creation, management, removal, tracking which Unix login has which web account, and so on). The follow on benefit from this is that it is very easy to put authentication restrictions on something, because we need basically no new infrastructure. The second advantage is that because we use HTTP Basic Authentication in Apache itself, we can use it to protect anything. Apache is perfectly happy to impose authentication in front of static files, entire directory hierarchies, CGIs, or full scale web applications, whatever you want. For CGIs and full scale web applications, you can generally pass on the authenticated user name, which comes in handy for things that want that sort of information. This makes it quite easy to build a new service that needs authentication, since all of the work is done for you. The third advantage is that when we put HTTP Basic Authentication in front of something, we don't have to trust that thing as much. This isn't just an issue of whether we trust its own authentication system (when it has one); it's also how much we want to have to trust the attack surface it exposes to unauthenticated people. When Apache requires HTTP Basic Authentication up front, there is no attack surface exposed to unauthenticated people; to even start talking to the real web app, you have to have valid login credentials. We have to trust Apache, but we were doing that already. (Of course this does nothing to protect us from someone who can get the login credentials of a user who has access to whatever it is, but that exposure is always there.) In an environment of sophisticated web services and web setups, there are probably ways to get all of this with something other than HTTP Basic Authentication. However, we don't have such an environment. We do not do a lot with web servers and web services, and our need for authentication is confined to things like [[our account request handling system ../python/DjangoORMDesignPuzzleII]], [[our self-serve DHCP registration portals ../sysadmin/DHCPPortalOverview]], [[small CGI frontends to let people avoid the Unix command line ../sysadmin/OurSelfserveAutoreplies]], and various internal sysadmin services. At this modest level, the ease of Apache's Basic HTTP Authentication is very much appreciated.