General ⋅ 6 min read

Authentication Protocols: Types and Uses

Ronak Massand ⋅ Jan 15, 2023

What is an Authentication Protocol?

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.

Application Layer Protocols

Kerberos

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. kerberos_protocol

When should you use Kerberos?

Environments with sensitive data: Kerberos provides a high level of security, making it suitable for on-premise environments with sensitive data, such as financial institutions and healthcare organizations.

Lightweight Directory Access Protocol (LDAP)

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. LDAP

When should you use LDAP?

Situations where on-premise authentication is needed
Situations where organizations want to maintain their own directory: LDAP allows organizations to maintain directories to store and manage user information, such as passwords, email addresses, and other data, on their own servers.

Security Assertion Markup Language (SAML)

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 john.doe@example.com, 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.

SAML

When should you use SAML?

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)

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.

When should you use CAS?

Situations where security is a priority: Credentials are less likely to get compromised using CAS protocol as applications never see them
Situations where multi-tier authentication is required: CAS uses a proxy address to authenticate users. A database server or mail server can be used as an intermediary to validate the identity of the user from the information it received from the application. Other identifying parameters or criteria can be defined on this trusted and safe proxy server, enabling a multi-tier authentication service.

OpenID

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.

When should you use OpenID?

The authentication is offloaded to the OpenID provider, and their security systems can be leveraged. Anyone can become an OpenID Provider without requiring third-party registration/approval

OAuth

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. OAuth

When should you use OAuth?

Situations where user convenience is a priority: OAuth provides a convenient and user-friendly way for users to grant access to their data, making it useful in situations where user convenience is a priority, such as in e-commerce applications.
Situations where users need to grant access to their data: OAuth enables users to grant access to their data to third-party applications or services, without having to share their login credentials. This makes it useful in situations where users need to grant access to their data, such as when using a fitness tracker app that needs access to their health data.
Environments with multiple service providers: OAuth allows users to grant access to their data to third-party service providers without sharing their login credentials. This makes it useful in environments with multiple service providers, such as social media networks.

Link Layer Protocols

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.

Password Authentication Protocol (PAP)

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.

When should you use PAP?

Situations where it is okay to transfer plain text credentials for authentication because the link over which it travels is itself secure.
Situations where the plaintext password must be available at the remote host to simulate a login or to match it against stored copy/hash.

Challenge-Handshake Authentication Protocol (CHAP)

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.

When should you use CHAP?

Situations where the link is susceptible to eavesdropping

Extensible Authentication Protocol (EAP)

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.

When should you use EAP?

Situations where the flexibility of choosing an authentication mechanism is required

Terminal Access Controller Access-Control System (TACACS)

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.