3 ms·

> Kerberos as a much saner SSO system than OAuth. +1, it really solves nearly all the authn and federation problems. You still find KDC installations in plac

> Kerberos as a much saner SSO system than OAuth. +1, it really solves nearly all the authn and federation problems. You still find KDC installations in places with large *nix footprints. Sometimes it's AD, sometimes it's MIT with a cross-realm trust. It's incredibly flexible and transparent to the user. It's easy for sysadmins, and various service owners to implement as it's basically drop a keytab in place, and set an environment variable for many daemons and libraries. IMO, the only reason it fell out of favor with the web crowd is there wasn't a gaggle of centralized providers that let them stand up services without thinking about the infrastructure. It wasn't packaged up nicely.

codebje 3y ago
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.
- jcranmer 3y ago
  > 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.
  - codebje 3y ago
    The OS is the fully trusted client - but you can't repeat that trick for a web app running on a remote server.
- mattpallissard 3y ago
  > 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.
throwaway2037 3y ago
As a developer that needs to use Kerberos for authentication between hosted services, I can say that Kerberos is simply awful to debug. When you have a failed login (refuse to auth), it is so hard for the _average_ developer to debug. We have pages and pages of cookbook solutions to various problems. Some issues are purely due to Kerberos complexity, and other issues are due to each programming language and their implementation of Kerberos. Most developers have no idea how SPNEGO works (Kerberos auth over HTTPS). I spend a lot of time on these issues, and I only have a surface understanding of SPNEGO. Oh yeah, and there are many subtle issues of Microsoft Active Directory (AD) vs MIT Kerberos.

codebje 3y ago

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.

jcranmer 3y ago
> 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.
- codebje 3y ago
  The OS is the fully trusted client - but you can't repeat that trick for a web app running on a remote server.
mattpallissard 3y ago
> 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.

throwaway2037 3y ago

As a developer that needs to use Kerberos for authentication between hosted services, I can say that Kerberos is simply awful to debug. When you have a failed login (refuse to auth), it is so hard for the _average_ developer to debug. We have pages and pages of cookbook solutions to various problems. Some issues are purely due to Kerberos complexity, and other issues are due to each programming language and their implementation of Kerberos. Most developers have no idea how SPNEGO works (Kerberos auth over HTTPS). I spend a lot of time on these issues, and I only have a surface understanding of SPNEGO. Oh yeah, and there are many subtle issues of Microsoft Active Directory (AD) vs MIT Kerberos.