Authentication is the process of determining whether a user is who they claim to be.
More formally, authentication protocols define the contents of the authentication data itself, the mode of its transfer, and the communication that must take place between two entities (server and client) in a network.
No Authentication protocol is completely secure and yet each offers adequate security and advantages in specific contexts. We discuss several of these protocols and the context of their use.
The Kerberos protocol (1988, spec) uses time-limited and encrypted tickets to validate clients and servers over an insecure network. Once authenticated, the user can transparently access all resources on the network they are authorized to access.
Even though LDAP (2006, spec) is often clubbed into various authentication protocols, it is really a directory and access management protocol that defines how one should talk to a directory server. It works on TCP/IP. Most systems use LDAP to talk to a directory to retrieve user accounts, verify them, and access attributes associated with these accounts.
SAML (2008, spec) is an XML-based framework for describing and exchanging assertions that applications working across security domain boundaries can trust. E.g. a typical assertion from an identity provider (IdP) would convey, “This user is John Doe, with the email address firstname.lastname@example.org, and was authenticated using a password mechanism.” A service provider (SP) could choose to use this information, depending on its access policies, to grant John Doe web SSO access to local resources.
Situations where you do not want to create and maintain user information directories
Situations where security, as well as user experience are important
SAML provides increased security in addition to improving the user experience. Because the identity provider stores all login information, the service provider does not need to keep user credentials on their system. Additionally, the identity provider can devote time and resources to implementing multiple layers of security because they specialize in providing secure SAML authentication.
Central Authentication Service (CAS) is a single sign-on protocol where the authentication process can only happen on the CAS server, so applications that authenticate with CAS never see the user’s credentials.
OpenID (spec) was created to solve SSO for non-enterprise end users. It allowed end users to specify URLs as their identifiers. e.g. An end user claiming http://www.example.com as their identifier, would include a link to their IdP in the HEAD section of the HTML document served by http://www.example.com. OpenId was never widely used but led to the evolution of OIDC.
While SAML and OpenID enabled end users (Resource Owners) to SSO for protected resources, there was still no mechanism to authorize applications to directly access users' resources without the end user's credentials. OAuth (2010, RFC 5849) enabled this by verifying not only the end user's authorization to access the resource but also the identity of the application making the resource request. e.g. applications using Google’s API often rely on OAuth to act on behalf of the end user.
The protocols discussed so far are application layer protocols and the more frequently encountered ones. There are other lower-layer protocols that are less frequently encountered because as end users we don’t have to deal with them directly.
PAP (1992, RFC 1334) is an authentication protocol used between two directly linked nodes. It is used only at the initial link establishment phase where the client uses a two-way handshake to establish its identity to the server. In the handshake, an ID and password pair is sent to the server as plain text and the server matches the ID-password pair against a local copy/hash.
CHAP (1992, RFC 1334) is another authentication protocol used between two directly linked nodes. It is used during the initial link setup phase and may be repeated later for re-verification. It uses a three-way handshake where the server sends a unique and unpredictable "challenge" message to the client. The client responds with a value calculated using a "one-way hash" function. The server checks the response against its own calculation of the expected hash value.
EAP (1998, RFC 2284) is another authentication protocol used between two directly linked nodes. It is extensible in that it supports multiple authentication mechanisms including the use of another authentication server. The server sends a request to authenticate the client but unlike CHAP where the information exchange is fixed, a request in EAP specifies the type of information being requested e.g. Identity, OTP, MD5-challenge, etc. The client responds with the requested information which the server validates.
The original TACACS protocol (1984, RFC 1492) defined how end users, who want to use a dial-up line, should authenticate to a TACACS server by sending a username and password. The criteria for authentication was left open for the TACACS authentication server which could use, in addition, other parameters such as time of day or other users already using the network.