List of Authentication Protocols

In this post I want to list the most common and used authentication protocols and frameworks today.

LDAP

LDAP, the Lightweight Directory Access Protocol, is a mature, flexible, and well supported standards-based mechanism for interacting with directory servers. It’s often used for authentication and storing information about users, groups, and applications, but an LDAP directory server is a fairly general-purpose data store and can be used in a wide variety of applications.

It’s a standards-based protocol that sits on top of TCP/IP and allows clients to perform a variety of operations in a directory server, including storing and retrieving data, searching for data matching a given set of criteria, authenticating clients, and more. The standard TCP ports for LDAP are 389 for unencrypted communication and 636 for LDAP over a TLS-encrypted channel, although it’s not uncommon for LDAP servers to listen on alternate ports for a variety of reasons.

Source: https://ldap.com/

Learn About LDAP
https://ldap.com/learn-about-ldap

Directory Servers

A directory server (more technically referred to as a Directory Server Agent, a Directory System Agent, or a DSA) is a type of network database that stores information represented as trees of entries. This is different from a relational database, which uses tables comprised of rows and columns, so directory servers may be considered a type of NoSQL database (even though directory servers have been around a lot longer than the term NoSQL has).

While virtually all directory servers support LDAP, some servers offer support for additional protocols that can be used to interact with the data. Some of these protocols include X.500 (the original Directory Access Protocol, for which LDAP is a much more lightweight version), naming service protocols like DNS and NIS, HTTP-based protocols like DSML and SCIM, and proprietary protocols like Novell’s NDS.

See Directory Servers for more information about the most popular directory servers.

Links
https://ldap.com/
https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

Kerberos

Invented at MIT, Kerberos is used extensively under the hood by Microsoft as the authentication protocol for Windows and Windows-related systems.

The primary benefit in Windows networks is the ability to automatically sign-in users to any resources connected to the domain. With the steady move to SaaS-based applications, Kerberos has become a less important authentication protocol, but it is still used widely by Microsoft for their on-prem domain controller. Also, it’s important to note that, with the changing IT landscape, many organizations have shifted away from an on-prem domain to the domainless enterprise architecture, relegating Kerberos to be somewhat less relevant than it was a decade or so ago.

Source: https://jumpcloud.com/blog/protocols-using-identity-management

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberos is available in many commercial products as well.

Source: https://web.mit.edu/kerberos/

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades. Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other’s identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication. Kerberos uses UDP port 88 by default.

Microsoft Windows

Windows 2000 and later versions use Kerberos as their default authentication method. Some Microsoft additions to the Kerberos suite of protocols are documented in RFC 3244 “Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols”. RFC 4757 documents Microsoft’s use of the RC4 cipher. While Microsoft uses and extends the Kerberos protocol, it does not use the MIT software.

Kerberos is used as the preferred authentication method: in general, joining a client to a Windows domain means enabling Kerberos as the default protocol for authentications from that client to services in the Windows domain and all domains with trust relationships to that domain.

In contrast, when either client or server or both are not joined to a domain (or not part of the same trusted domain environment), Windows will instead use NTLM for authentication between client and server.

Intranet web applications can enforce Kerberos as an authentication method for domain-joined clients by using APIs provided under SSPI.

Unix and other operating systems

Many Unix-like operating systems, including FreeBSD, OpenBSD, Apple’s macOS, Red Hat Enterprise Linux, Oracle’s Solaris, IBM’s AIX, HP-UX and others, include software for Kerberos authentication of users or services. A variety of non-Unix like operating systems such as z/OS, IBM i and OpenVMS also feature Kerberos support. Embedded implementation of the Kerberos V authentication protocol for client agents and network services running on embedded platforms is also available from companies.

Source: https://en.wikipedia.org/wiki/Kerberos_(protocol)

Security Support Provider Interface (SSPI) 
https://en.wikipedia.org/wiki/Security_Support_Provider_Interface
SSPI functions as a common interface to several Security Support Providers (SSPs): A Security Support Provider is a dynamic-link library (DLL) that makes one or more security packages available to apps.

Kerberos (kerberos.dll) – Introduced in Windows 2000 and updated in Windows Vista to support AES. Performs authentication for Windows domains in Windows 2000 and later.

NTLM

NTLM authentication is a family of authentication protocols that are encompassed in the Windows Msv1_0.dll. The NTLM authentication protocols include LAN Manager version 1 and 2, and NTLM version 1 and 2. The NTLM authentication protocols authenticate users and computers based on a challenge/response mechanism that proves to a server or domain controller that a user knows the password associated with an account. When the NTLM protocol is used, a resource server must take one of the following actions to verify the identity of a computer or user whenever a new access token is needed:

• Contact a domain authentication service on the domain controller for the computer’s or user’s account domain, if the account is a domain account.
• Look up the computer’s or user’s account in the local account database, if the account is a local account.

NTLM authentication is still supported and must be used for Windows authentication with systems configured as a member of a workgroup. NTLM authentication is also used for local logon authentication on non-domain controllers. Kerberos version 5 authentication is the preferred authentication method for Active Directory environments, but a non-Microsoft or Microsoft application might still use NTLM.

Source: https://docs.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview

Security Support Provider Interface (SSPI) 
https://en.wikipedia.org/wiki/Security_Support_Provider_Interface
SSPI functions as a common interface to several Security Support Providers (SSPs): A Security Support Provider is a dynamic-link library (DLL) that makes one or more security packages available to apps.

NTLMSSP (msv1_0.dll) – Introduced in Windows NT 3.51. Provides NTLM challenge/response authentication for Windows domains prior to Windows 2000 and for systems that are not part of a domain.

Links
https://de.wikipedia.org/wiki/NTLM
https://docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/ntlm-user-authentication

Predecessor of NTLM
https://en.wikipedia.org/wiki/LAN_Manager

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is an authentication protocol primarily used by networking solutions such as wireless networks, VPNs, and network infrastructure equipment. RADIUS servers generally connect back to a central directory service which contains user credentials. RADIUS was primarily used by ISPs and the like early on, but has since been repurposed to control WiFi networks and VPNs.

Source: https://jumpcloud.com/blog/protocols-using-identity-management

Links
https://en.wikipedia.org/wiki/RADIUS

How Does RADIUS Work?
https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/12433-32.html

Oauth2

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.

Generally, OAuth provides clients a “secure delegated access” to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without providing credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

OAuth is directly related to OpenID Connect (OIDC), since OIDC is an authentication layer built on top of OAuth 2.0.

Source: https://en.wikipedia.org/wiki/OAuth

Open ID | OpenID Connect (OIDC)

Another authentication mechanism for web applications, OpenID has gained some adoption due to support from significant consumer facing web applications such as Google^® and Yahoo!. OpenID works similar to SAML but is less complex to implement. Using OpenID, a third party web application could allow users to log in to their services via a Google, Microsoft, Facebook, Twitter, or Yahoo ID, for example.

Source: https://jumpcloud.com/blog/protocols-using-identity-management

OpenID is an open standard and decentralized authentication protocol. Promoted by the non-profit OpenID Foundation, it allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each. Users create accounts by selecting an OpenID identity provider and then use those accounts to sign onto any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites, according to the OpenID Foundation.

The final version of OpenID is OpenID 2.0, finalized and published in December 2007.

Published in February 2014 by the OpenID Foundation, OpenID Connect is the third generation of OpenID technology. It is an authentication layer on top of the OAuth 2.0 authorization framework. It allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain the basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.

OpenID Connect (OIDC) allows a range of parties, including web-based, mobile and JavaScript clients, to request and receive information about authenticated sessions and end-users. The OpenID Connect specification is extensible, supporting optional features such as encryption of identity data, discovery of OpenID providers, and session management

Source: https://en.wikipedia.org/wiki/OpenID

SAML | SAML2.0

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions (statements that service providers use to make access-control decisions). SAML is also:

• A set of XML-based protocol messages
• A set of protocol message bindings
• A set of profiles (utilizing all of the above)

An important use case that SAML addresses is web-browser single sign-on (SSO). Single sign-on is relatively easy to accomplish within a security domain (using cookies, for example) but extending SSO across security domains is more difficult and resulted in the proliferation of non-interoperable proprietary technologies. The SAML Web Browser SSO profile was specified and standardized to promote interoperability.

The most current version of SAML is SAML 2.0 and became OASIS Standard in March 2005.

Source: https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information. SAML is fast becoming the technology of choice to provide cross-vendor single sign-on (SSO) interoperability.

OASIS
https://www.oasis-open.org/
https://en.wikipedia.org/wiki/OASIS_(organization)

The Organization for the Advancement of Structured Information Standards (OASIS) is a global nonprofit consortium that works on the development, convergence, and adoption of open standards for cybersecurity, blockchain, Internet of Things (IoT), emergency management, cloud computing, legal data exchange, energy, content technologies, and other areas.

A SAML assertion is an XML-formatted token that is used to transfer user identity and attribute information from the identity provider of a user to a trusted service provider as part of the completion of a single sign-on request. A SAML assertion provides a vendor-neutral means of transferring information between federation business partners.

As a protocol, SAML has three versions: SAML 1.0, SAML 1.1, and SAML 2.0. SAML 2.0 is an enhancement to the previous SAML 1.x specifications, but is not backwards compatible.

SAML 2.0 defines several request-response protocols, which all correspond to the action being communicated in the message. These protocols are HTTP-redirect based and involve the user’s browser. SAML 2.0 has defined several binding options, HTTP redirect, HTTP POST, HTTP artifact, and SOAP. These options specify the way in which messages can be transported. SAML 2.0 HTTP POST enables SAML protocol messages to be transmitted within an HTML form using base64-encoded content. SAML 2.0 HTTP POST enables the SAML provider and consumer to communicate using an HTTP user agent as an intermediary. HTTP POST is sometimes called Browser POST, particularly when used in single sign-on operations. SAML 2.0 Web Browser SSO Profile is defined to support web single sign-on. A web user either accesses a resource at a service provider, or accesses an identity provider such that the service provider and desired resource are understood or implicit. The web user authenticates to the identity provider, which then produces an authentication assertion, and the service provider consumes the assertion to establish a security context for the web user.

Source: https://www.ibm.com/docs/en/was-zos/9.0.5?topic=users-saml-web-single-sign

WS-Trust

WS-Federation operates directly on top of the HTTP protocol and, specifically for AD FS, only with passive requesters, that is, web browsers. There is a class of applications that is not covered in the WS-Federation scenarios as implemented in AD FS, namely SOAP-based applications. These applications can also benefit from federation and the use of security tokens for purposes that are similar to those for WS-Federation.

The Web Services Trust Language [WSTrust] is available in AD FS to accommodate SOAP-based applications.

Source: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adfsod/e29e94c8-2e59-45ae-9b1c-943de1966ae8

WS-Trust is a WS-* specification and OASIS standard that provides extensions to WS-Security, specifically dealing with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.

The WS-Trust specification was authored by representatives of a number of companies, and was approved by OASIS as a standard in March 2007.

Using the extensions defined in WS-Trust, applications can engage in secure communication designed to work within the Web services framework.

Source: https://en.wikipedia.org/wiki/WS-Trust

WS-Federation (WS-Fed)

WS-Federation is part of the larger Web Services Security (WS-Security) framework which provides a means for applying security to web services through the use of security tokens. WS-Security describes how to attach signature and encryption headers as well as security tokens (including binary security tokens such as X.509 certificates and Kerberos tickets) to SOAP messages. WS-Trust, another specification in the WS-Security framework, provides for federation by defining a Security Token Service (STS) and a protocol for requesting and issuing the security tokens. WS-Federation, as implemented in OpenSSO Enterprise, uses the OpenSSO Enterprise Security Token Service (modelled on the WS-Trust specification) to allow providers in different security realms to broker trust using information on identities, identity attributes and authentication, and provider federation. A principal requests a token from the Security Token Services. This token, which may represent the principal’s primary identity, a pseudonym, or the appropriate attributes, is presented to the service provider for authentication and authorization. WS-Federation uses several security tokens as well as the mechanism for associating them with messages. This release of OpenSSO Enterprise has implemented the following features of the WS-Federation specification.

Source: https://docs.oracle.com/cd/E19316-01/820-3740/ggkkw/index.html

Web Services Federation Language (WS-Federation) 
http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html

WS-Federation comes with a passive and active profile.

WS-Federation Passive Requestor Profile
https://en.wikipedia.org/wiki/WS-Federation_Passive_Requestor_Profile
Passive Clients (Browser )

WS-Federation Active Requestor Profile
https://en.wikipedia.org/wiki/WS-Federation_Active_Requestor_Profile
Smart Active Clients (SOAP)

Active, Passive and Passive-Aggressive
https://www.cloudidentity.com/blog/2008/06/05/active-passive-and-passive-aggressive/

A great post about passive authentification you will find below.

Passive Federation Basics
https://docs.microsoft.com/en-us/archive/msdn-magazine/2010/august/federated-identity-passive-authentication-for-asp-net-with-wif#passive-federation-basics

Passive federation scenarios are based on the WS-Federation specification. This describes how to request security tokens and how to publish and acquire federation metadata documents, which makes establishing trust relationships easy. WS-Federation also describes single sign-on and sign-out procedures and other federation implementation concepts.

While WS-Federation discusses many details about federation, there are sections devoted to browser-based federation that rely on HTTP GET and POST, browser redirects and cookies to accomplish the goal.

Some aspects of passive federation messaging are based closely on the WS-Trust specification. For example, passive federation employs a browser-compatible form of Request Security Token (RST) and RST Response (RSTR) when a security token is requested of an STS. In the passive federation scenario, I’ll call the RST a sign-in request message and the RSTR a sign-in response message. The WS-Trust specification focuses on SOAP-based (active) federation, such as between Windows clients and WCF services.

Simple Passive Federation Scenario

Users authenticate to their domain and are granted access to a Web application according to their roles. The participants in this authentication scheme include the user (the subject), a Web browser (the requester), an ASP.NET application (the relying party or RP), an IdP responsible for authenticating the users within its domain and an STS belonging to the user’s domain (IP-STS). A sequence of browser redirects ensures that the user is authenticated at her domain prior to accessing the RP.

Source: https://docs.microsoft.com/en-us/archive/msdn-magazine/2010/august/federated-identity-passive-authentication-for-asp-net-with-wif#passive-federation-basics

Integrated Windows Authentication (IWA)

Integrated Windows Authentication itself is not a standard or an authentication protocol. When IWA is selected as an option of a program implies  underlying security mechanisms should be used in a preferential order. If the Kerberos provider is functional and a Kerberos ticket can be obtained for the target, and any associated settings permit Kerberos authentication to occur (e.g. Intranet sites settings in Internet Explorer), the Kerberos 5 protocol will be attempted. Otherwise NTLMSSP authentication is attempted. Similarly, if Kerberos authentication is attempted, yet it fails, then NTLMSSP is attempted. IWA uses SPNEGO to allow initiators and acceptors to negotiate either Kerberos or NTLMSSP. Third party utilities have extended the Integrated Windows Authentication paradigm to UNIX, Linux and Mac systems.

Source: https://doubleoctopus.com/security-wiki/federation-and-sso/single-sign-on/

SPNEGO

SPNEGO itself is not an authentication protocol.

Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), often pronounced “spenay-go”, is a GSSAPI “pseudo mechanism” used by client-server software to negotiate the choice of security technology. SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports. The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.

SPNEGO’s most visible use is in Microsoft’s “HTTP Negotiate” authentication extension. It was first implemented in Internet Explorer 5.01 and IIS 5.0 and provided single sign-on capability later marketed as Integrated Windows Authentication. The negotiable sub-mechanisms included NTLM and Kerberos, both used in Active Directory. The HTTP Negotiate extension was later implemented with similar support in:

• Mozilla
• Mozilla Firefox
• Konqueror
• Google Chrome

Source: https://en.wikipedia.org/wiki/SPNEGO

WebAuthn / FIDO2 Project

Web Authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). WebAuthn is a core component of the FIDO2 Project under the guidance of the FIDO Alliance. The goal of the project is to standardize an interface for authenticating users to web-based applications and services using public-key cryptography.

On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an authenticator, which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor’s trusted execution environment or a Trusted Platform Module (TPM). Sensitive cryptographic operations can also be offloaded to a roaming hardware authenticator that can in turn be accessed via USB, Bluetooth Low Energy, or near-field communications (NFC). A roaming hardware authenticator conforms to the FIDO Client to Authenticator Protocol (CTAP), making WebAuthn effectively backward compatible with the FIDO Universal 2nd Factor (U2F) standard.

The WebAuthn Level 1 standard was published as a W3C Recommendation on 4 March 2019. A Level 2 specification is under development.

Source: https://en.wikipedia.org/wiki/WebAuthn

FIDO2 Project
https://en.wikipedia.org/wiki/FIDO2_Project

The FIDO2 Project is a joint effort between the FIDO Alliance and the World Wide Web Consortium (W3C) whose goal is to create strong authentication for the web. At its core, FIDO2 consists of the W3C Web Authentication (WebAuthn) standard and the FIDO Client to Authenticator Protocol 2 (CTAP2). FIDO2 is based upon previous work done by the FIDO Alliance, in particular the Universal 2nd Factor (U2F) authentication standard.

Simple Authentication and Security Layer (SASL) 

Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL.

A list of authentication mechanism SASL will support you can see here
https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer#SASL_mechanisms

ANONYMOUS
PLAIN
OTP
DIGEST-MD5
NTLM
GSSAP for Kerberos
Oauth

….

SASL is used for example from SMTP, IMAP, POP3, LDAP and XMPP.

Example how Postfix uses SASL authentication

SMTP servers need to decide whether an SMTP client is authorized to send mail to remote destinations, or only to destinations that the server itself is responsible for. Usually, SMTP servers accept mail to remote destinations when the client’s IP address is in the “same network” as the server’s IP address.

SMTP clients outside the SMTP server’s network need a different way to get “same network” privileges. To address this need, Postfix supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it “same network” privileges.

Postfix does not implement SASL itself, but instead uses existing implementations as building blocks. This means that some SASL-related configuration files will belong to Postfix, while other configuration files belong to the specific SASL implementation that Postfix will use.

Source: http://www.postfix.org/SASL_README.html

Links
https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml