> Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. That's incorrect. The client doesn't

> Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. That's incorrect. The client doesn't need to be trusted at all. There is also there anonymous auth, certs via pkinit (which give you yubiki and piv/cac cards as well), and otp. > Kerberos was never popular with the web crowd because it's not capable of solving the problem of authorizing web applications. In MS kerberos, group membership comes over with a TGT in the from of a PAC. > Before OAuth everywhere just asked for your username and password to log in on your behalf. I'm taking about kerberos, you'd use a TGT to log into that service. > And the only reason Kerberos works well today is that it's always now a single-vendor solution, homogeneous across the deployment. It's an interoperability nightmare otherwise. There are a lot of cross realm trusts between MIT/AD and Heimdall/AD, and they just work. It really isn't difficult. As I said in my original comment, it's just that it wasn't packaged up nicely. All the parts are there.