Web Authentication Schemes

A web authentication scheme is a method or recipe to pass credentials from a user to an authenticating system. These schemes vary in their security and complexity with some only handling authentication while others can also handle authorization. Additional techniques such as LTPA can layer on single-sign-on capabilities. Furthermore SSL/TLS is used to ensure confidentiality and is a required prerequisite from which these other authentication schemes rely upon. Note that it is the responsibility of the authenticating system to actually check the credentials and grant access to resources. These triple-A security systems are typically turnkey products based on technologies like Kerberos, NTLM, and LDAP to name a few.

• SSL/TLS Mutual Authentication
• HTTP basic auth
• HTTP form-based auth
• DAA
• LTPA
• OAuth2
• OpenID
• OpenID Connect
• SAML

(taken from my Mobile Application Enterprise Environment doc)

SSL/TLS

Generally SSL is an integral part of many, if not all web authentication schemes since a secure channel is required before exchanging credentials.  The central concept in SSL/TLS is the digital certificate and how they form a chain of trust.

Digital Certificates

A digital or public key certificate is an electronic document that proves ownership of a public key. The certificate contains details about the key, owner information and a digital signature of a certificate authority who vouches for all the contents. Digital certificates and certificate authorities (CA) are central to a public key infrastructure (X.509 PKI). Every web client has a default collection of certificates from major certificate authorities. These are included with browsers and in Java’s cacerts file. This default collection consists of hundreds of root authorities such as Verisign or GeoTrust. Each certificate is signed by a single authority. In turn, the certificate of the signer is signed by another authority, each one becoming more widely accepted. Finally the root certificate of the chain is self signed and widely distributed. This root certificate is the anchor of trust in PKI and is used to validate the entire certification tree. Any certificate can be trusted if it has been signed by a CA.  By far the most common use of digital certificates is in establishing secure SSL/TLS based channels of communication between clients and HTTPS based web sites.

SSL Details

SSL authentication can take two forms: simple and mutual (also known as 1-way and 2-way authentication). 1-way authentication is usually what occurs whenever an HTTPS connection is established. With each 1-way SSL connection, the server provides the client with its certificate which the client then verifies against it’s own collection of digital certificates that it trusts. If the server certificate isn’t found, but is signed by a certificate that the client does trust, then the client also trusts the server (hence the ‘chain of trust’). This interaction requires 9 handshake messages between the client and server before the secure channel is established.

In mutual SSL authentication, everything that occurred in the 1-way interaction still happens, plus the server also requests the client’s digital certificate and checks it’s own collection of trusted certificates to determine if it can trust the client. This entire exchange requires a total of 12 handshake messages. Generally mutual SSL authentication is used in server-to-server scenarios. It is possible to use SSL mutual authentication exclusively without the need for any other web authentication scheme, but requires that either: 1) all users have a personal digital certificate signed by a root certificate authority or 2) the server imports each user’s certificate into its trusted certificate store. Neither of these requirements scales, hence the alternatives that follow.

TLS-SRP was introduced as a means to provide password-based client authentication to the server without the need for client certificates. While it addresses the usability issues of managing client certificates, TLS-SRP was never widely adopted and suffers from being generally accepted.

HTTP Basic Auth

Basic authentication has no cookies, no handshakes and really is as basic as authentication can be made. It uses a dedicated HTTP header to communicate the encoded  username and password on every request that needs authentication. This requires that the client (usually a browser) cache the credentials for a period of time, otherwise the user would be prompted for login repeatedly. Since the credentials are essentially transmitted in the clear, HTTP Basic Auth must be paired with SSL/TLS.  While simple to use and understand HTTP Basic Auth has the following drawbacks:

• no standard way to logout
• no way to customize the login experience
• client needs to prompt user for credentials, collect and encode into the header (this is done by the browser)
• client needs to securely cache credentials for a reasonable period
• fundamentally insecure since the full credentials pass over the wire

HTTP Form-based Auth

Form-based authentication is the most popular form of authentication chiefly because of it’s simplicity as well as allowing the login experience to the completely customized (unlike basic auth). While the technique is simple, basically just prompt the user for a username and password using a custom HTML form and send those credentials to the server in the next request, there is no standardization and implementations are ad-hoc. For example the authentication endpoint URL can be anything, as can the names of the username and password fields (the Java Servlet Specification standardizes on using j_security_check as the endpoint URL and j_username, j_password for the credential fields). So unlike basic auth, using form-based auth requires the implementer to prompt for user credentials and send them to the server, as well as the other responsibilities of caching the credentials for a period of time and securely transmitting them. HTTP form-based auth requires the use of SSL/TLS connections since the full credentials are exchanged between parties.

Digest Access Authentication (DAA)

DAA is meant to address the fact that Basic Auth sends the full credentials to the server where as DAA only sends a MD5 hash of the credentials. It includes some additional features such as a nonce as protection against replay attacks. However, the Digest Access Authentication scheme is married to MD5 which excludes it from FIPS approval (MD5 is flawed since the hash it produces is not collision resistant). Furthermore much of the spec remains optional so compliant implementation may not implement all the protections described by DAA. While better than Basic Auth and is supported by most browsers, DAA has been superseded by more secure authentication protocols due to its reliance on MD5. Since the username, password and realm are hashed before being sent to the server, a secure channel may not seem necessary. Unfortunately without it, DAA is susceptible to man-in-the-middle (MITM) interception attacks

Lightweight Third-Party Authentication (LTPA)

LTPA is an IBM proprietary method of achieving Single Sign-On (SSO). As such it must be used in conjunction with another authentication technique to initially authenticate a user. Once the user is logged in, then an LTPA token (cookie) is created. When this cookie is passed to other servers in the same domain (as defined in the cookie), that server can decrypt the LTPA token and extract the authenticated user information (including the realm and time of login), enabling an automatic login. In order to accomplish this all hosts participating in SSO must have a shared key and have their clocks synchronized. Since the contents of LTPA tokens are encrypted their transmission via SSL/TLS is not strictly needed. However it is considered good practice to only pass the cookie via a secure channel and to prevent access to it client-side (via HttpOnly flag) to thwart cross-site scripting attacks since the cookie is really only needed by the servers.

OAuth 2

Strictly speaking, OAuth 2 is an authorization scheme, although it can be co-opted into also acting as an authentication scheme. OAuth 2 allows a provider application to grant access to some specific resource to a consumer application.

Before beginning the OAuth process, the consumer application must first register with the provider application. This is a manual, one-time process that typically involves providing basic information such as application name, website, a logo, etc. Most importantly, a redirect URI to be used for redirecting users from the provider back to the consumer web server, browser-based, or mobile app must be provided to prevent certain attack vectors.

The sequence starts with the consumer making a (OAuth2) resource request to the provider. The provider application informs the user of the request and prompts them to authenticate if they haven’t already done so. The way the provider authenticates the user has nothing to do with OAuth2. Any authentication scheme can be used. Once the user is authenticated and has granted permission to the provider application, control reverts back to the consumer (via the registered redirect URI) which now has an access token that allows it access to the resource on the provider. This access token is provided in the HTTP header for subsequent requests. The specifics of this interaction between consumer and provider vary depending upon whether they are server-hosted web sites, browser based-apps or mobile applications. What makes OAuth2 notable is the fact that the user’s credentials are never exposed to the consumer application. The consumer is only given a temporary token which can be revoked by the user or provider application at any time without any need for the credentials to change. OAuth2 mandates the use of SSL/TLS.

As mentioned earlier, OAuth2 can also be used for authentication. The specification provides a “password” grant type which can be used to pass credentials directly to the provider application for an access token directly.Of course this requires that the client collect those credentials from the user. OAuth purists debate against this, though in cases where the consumer and provider are the same application this does make sense and simplifies interactions.

OpenID 2.0 (OID)

OpenID is an open standard for providing authentication of an identity. There are many OID identity providers (Google, Yahoo, Flickr, WorkPress to name a few). Any client that outsources authentication to one of these identity providers is know as a Relaying Party (RP).  The OpenID Attribute Exchange extension allows profile attributes, such as name and gender, to be provided from the OpenID identity provider to the relying party. Essentially OID allows a user to maintain a single profile (with an OID identity provider of their choice) and authenticate with any third-party website or mobile application that participates as a relaying party, obviating the need to maintain multiple login accounts. Furthermore, the user’s credentials are never seen by any RP. OpenID 2.0 has been superseded by OpenID Connect 1.0.

OpenID Connect 1.0 (OIDC)

OpenID Connect is the 3rd generation of OpenID that adds an authentication layer to the OAuth2 authorization protocol. In addition to authenticating a user’s identity, OIDC also describes how basic user profile information can be obtained (the provider/server must provide a new user info URI endpoint to support this). In a way, OIDC is an extension of OAuth2, with the addition of ‘openid’ and ‘profile’ scopes. The OAuth2 flow is unchanged. When an OIDC request is successful an access token and ID token are returned to the client (consumer).  The ID token can be used to ensure the request has not been tampered with. It is signed by the server using the client secret that was previously established over a trusted channel. The ID token is a specifically formatted JSON object that the client is obligated to validate. OIDC is the evolution of OAuth2 pseudo-authentication.

SAML 2.0

Security Assertion Markup Language (SAML) is an XML-based open standard for both authentication and authorization and is capable of exchanging user profile attributes as well. Previous versions of SAML relied on SOAP over HTTP, but version 2 has more flexible bindings, and if exchanges are between the user and identity provider, and user and service provider (called front channel exchanges), then SOAP is not necessary. SAML 2 and OIDC are different solutions to the same authentication and authorization challenge. SAML and OAuth2 can interoperate. Due to the extensible nature of OAuth2 in theory it is possible to use a SAML assertion as credentials to obtain an OAuth2 access token.

Authentication and Authorization Schemes Summary

HTTP Basic Auth and Digest are supported in the HTTP spec so these two schemes enjoy native browser support. Form-based auth is the most widely used technique but leaves many details to the implementor. OpenID, OpenID Connect and SAML (and OAuth2 if used that way) offer open standards for  federated identity authentication and web SSO. LTPA is an IBM proprietary means of providing domain-limited web SSO.

SAML is the current leading standard for inter-domain web SSO, but in the not-near future may be eclipsed by OIDC. OIDC, due to its virtue of being newer takes into account mobile application use cases, as well as uses JSON instead of XML as the message data format, whereas SAML 2 provides secure backchannel and SOAP capabilities.