Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client.
OAuth was invented to avoid the need to do that. If I use some finance package and I'd like it to download my transactions from my bank, I'd really rather not have to give it my username and password, with the full access that grants including the ability to lock me out of my bank account and transfer my money. OAuth lets you instead grant permissions for that program to do something more limited, like just read your transaction history.
Kerberos was never popular with the web crowd because it's not capable of solving the problem of authorizing web applications. Before OAuth everywhere just asked for your username and password to log in on your behalf.
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.
> Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client.
Not really. In practice, Kerberos means just loading the gssapi or sspi library, essentially using the user's login to already have the ticket-granting-ticket generated and usable for the subsequent tickets. As the client application, I never see the user's password; it's all handled for me by the OS.
> 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.
OAuth was invented to avoid the need to do that. If I use some finance package and I'd like it to download my transactions from my bank, I'd really rather not have to give it my username and password, with the full access that grants including the ability to lock me out of my bank account and transfer my money. OAuth lets you instead grant permissions for that program to do something more limited, like just read your transaction history.
Kerberos was never popular with the web crowd because it's not capable of solving the problem of authorizing web applications. Before OAuth everywhere just asked for your username and password to log in on your behalf.
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.