So having the ease of mind that when I block someone in Entra ID, they will also be locked out of all servers immediately—that would be great actually.
> PAM TOTP (or even just password+OTP) into HTTP auth
But why would you? Before initiating a session, users will have to authorise to the IdP, which probably includes MFA or Passkeys anyway. No need for PAM anymore at all.
It's done because the web stack exists and is understood by the web/infrastructure folks, not because it represents any kind of local design optima in the non-web space.
Using the web stack draws in a huge number of dependencies on protocols and standards that are not just very complex, but far more complex than necessary for a non-web environment, because they were designed around the constraints and priorities of the web stack. Complicated, lax, text-based formats easily parsed by javascript and safe to encode in headers/json/query parameters/etc, but a pain to implement anywhere else.
Work-arounds (origin checks, CORS, etc) for the security issues inherent in untrusted browsers/javascript being able to make network connections/etc.
We'be been using kerberos and/or fetching SSH keys out of an LDAP directory to solve this problem for literal decades, and it worked fine, but if that won't cut it, solving the SSH certificate tooling problem would be a MUCH lighter-weight solution here than adopting OAuth and having to tie your ssh(1) client implementation to a goddamn web browser.
All of that isn't really important, though. What makes a major point for using HTTP w/ TLS as a transport layer is the ecosystem and tooling around it. You'll get authorization protocols like OIDC, client certificate authentication, connection resumption and migration, caching, metadata fields, and much more, out of the box.
I have to disagree pretty strongly on this one. Case in point: WebSockets. That protocol switch is "nifty" but breaks fundamental assumptions about HTTP and to this day causes headaches in some types of server deployments.