Just to clarify - are you calling cookie support a huge middleware framework?
Both BasicAuth and Cookie reception are features included in nearly every browser offering - it's generally how you actually check resource authorization that's the hard part of Auth - the actual technical "Get a cookie from a browser" and "Check the BasicAuth headers" portions are pretty simple - in fact getting a cookie is arguably easier in most cases. Especially since a popular serverside programming language (PHP) has streamlined session handling to the point that most programmers going from it to other serverside languages get confused when there isn't a $_SESSION equivalent that you just inspect with the tap of a button.
Note that I said “authentication and accounting system”. You just described a very small part of that functionality. It’s the reason people adopt large frameworks like Django, and why PHP’s session management alone is insufficient.
You can look at functionality like Apache’s mod_authnz_ldap as an example of built in account management that integrates with HTTP basic auth.
Why would `Authentication` be any different to `Cookie` in this regard? They're both HTTP headers. They both require server side support/implementation. Neither explicitly requires JavaScript.
The only difference I can see is that the browser has a native control for one of them, though that control cannot be customised by the site.
Comments
Why is this preferable to authentication using cookies?
The web server can directly handle your authentication and accounting system rather than needing to include more huge middleware frameworks.
Just to clarify - are you calling cookie support a huge middleware framework?
Both BasicAuth and Cookie reception are features included in nearly every browser offering - it's generally how you actually check resource authorization that's the hard part of Auth - the actual technical "Get a cookie from a browser" and "Check the BasicAuth headers" portions are pretty simple - in fact getting a cookie is arguably easier in most cases. Especially since a popular serverside programming language (PHP) has streamlined session handling to the point that most programmers going from it to other serverside languages get confused when there isn't a $_SESSION equivalent that you just inspect with the tap of a button.
Note that I said “authentication and accounting system”. You just described a very small part of that functionality. It’s the reason people adopt large frameworks like Django, and why PHP’s session management alone is insufficient.
You can look at functionality like Apache’s mod_authnz_ldap as an example of built in account management that integrates with HTTP basic auth.
https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html
Why would `Authentication` be any different to `Cookie` in this regard? They're both HTTP headers. They both require server side support/implementation. Neither explicitly requires JavaScript.
The only difference I can see is that the browser has a native control for one of them, though that control cannot be customised by the site.