Standard Authentication Mechanisms

Introduction

There are multiple standards for authentication: SAML, OAuth, and OpenID Connect. This paper will compare and contrast these standards and explain the contexts in which they are best used. First, let’s clarify the definition of authentication. Authentication is the verification of someone’s identity. This is different than authorization: authorization is granting someone access to information based on who they are, and optionally, other criteria such as time of day.

We will touch on authorization briefly because some authentication standards support authorization to some extent. More specifically, there are two kinds of authorization: coarse-grained and fine-grained. An example of coarse-grained authorization is whether a user has access to a particular web application (or subset thereof). However, an example of fine-grained authorization is whether a user can see a particular field on a page, or whether they can perform a particular operation (e.g. button-click on a page). Regardless, one cannot authorize a user unless they are first authenticated. OAuth 2.0 supports coarse-grained authorization by returning the allowed scopes -- as a result of a successful authentication.

Authentication Mechanisms

There are three major standards for authenticating users on the internet and in the context of software-based identity verification: SAML, OAuth 2.0 and OpenID Connect. SAML was designed to allow a prior authentication to support a subsequent authentication to a different application (of the same user). This is typically referred to as Single Signon (SSO). The benefits of SSO are:

• Stronger security because fewer passwords are required, and users tend to expose their passwords when they have too many
  
• Increased efficiency for employees (less time logging into applications)
  
• Centralizes authentication to a single Identity Provider (IDP), and allows directories such as Active Directory to be used as the source-of-truth for user identity
  
• Facilitates automation such that new users can be automatically provisioned into the applications in which they have been granted access
  

SAML uses what I call a “trusted introduction” or “vouching” paradigm where, because the IDP is trusted as the gatekeeper and true authenticator, then if we establish trust between the IDP and various SAML-enabled applications (referred to as Service Providers or SPs), then the SP can trust that the IDP such that it vouches for the access of the user to that SP/application. This trust is established via public/private asymmetric key encryption between the IDP and the SP -- per the SAML protocol.

In contrast to this, OAuth 2.0 uses a “valet key” concept for granting access and authorization (not necessarily authentication). When a user wants to access an application (a “Resource Server” or RS), the RS requests the valet key (referred to as an access token) from an Authorization Server (AS) such as Facebook or Google. This access token can then be used to access the endpoint RS/application. OAuth does not support dynamic discovery, and therefore authorization applications must be hard-coded into the RS website.

Finally, OpenID Connect is essentially a layer on top of OAuth 2.0 that supports federated authentication. It leverages the valet key underpinnings in OAuth 2.0, but adds the concept of what some call a referral letter. The endpoint RS/application requests a referral letter (conceptually) from the AS (e.g. Google), and the AS uses the OAuth 2.0 protocol as the mechanism for message exchange. The AS could then be considered a “notary” using our metaphor. The AS stamps or notarizes the referral letter, and then this letter can be provided to the RS site -- whereby the RS accepts it and allows the user to access this RS/application. In the following sections we will explore these 3 authentication mechanisms in greater detail. OpenID Connect supports dynamic registration and discovery of the authentication providers as well as a login flow.

SAML Overview

SAML (we will limit this discussion to SAML 2.0) is the most mature authentication standard. The SAML standard came from the OASIS organization. However, dues to its complexity and use of PKE and XML, it was not a good fit for mobile devices and the proliferation of new social websites and applications. Having said that, SAML is the dominant enterprise authentication standard today, and several major vendors provide excellent products - both on-premise (e.g. Oracle, CA, Ping) and cloud-based (e.g. Okta and OneLogin).

From a technical standpoint, SAML leverages the concept of an Assertion -- which is a collection of standardized XML elements conveying a fact. There are 3 types of assertions: 1) authentication, 2) attribute, and 3) authorization. SAML also defines Protocols which are sets of message exchanges to achieve a particular function (e.g. Single Logout Protocol to log someone out of all the SAML sessions establish concurrently by the IDP). SAML also defines Profiles -- which are concrete use-cases of applied assertions. An example of a profile is the Web Browser SSO Profile. Finally, SAML defines Bindings. Bindings define how protocols and profiles can be implemented at the lower messaging layer. Examples are HTTP Post or SAML SOAP bindings.

WIth regard to configuring SAML, the following points will facilitate an understanding of how to implement SAML for a particular vendor configuration:

• SAML Issuer: Arbitrary identitier for IDP but must match the Issuer setup in SP configuration
  
• SAML Recipient: typically maps to a login URL
  
• SAML Audience: identifies the SP; this is often set to the top-level domain name of the SP application
  
• IDP Login URL: used for SP-initiated to redirect into IDP
  
• IDP Logout URL: useful for when user logs out of SP
  

Note that the IDP typically provides a PKE digital certificate to the SP out-of-band. The SP can then decode DigSig in SAML Assertion using IDP public key. And the asserted principle can either be the agreed upon user-name or it could be a federated ID (e.g. an Active Directory identifier). Finally, the SAML RelayState parameter can be used for conveying URLs among session request/responses (e.g. for deep-linking into the SP application). What follows is a good pictorial representation of the typical SAML message flows.

OAuth 2.0 Overview

OAuth is an IETF standard. It was designed to be friendlier to mobile devices and REST-based applications -- when compared to SAML. OAuth basically authorizes client programs to access resources on behalf of an end-user. OAuth 1.1 was more limited and complex than OAuth 2.0. Using OAuth terminology, the SP is now called a Resource Server, and the access tokens are obtained from an Authorization Server -- which is roughly analogous to a SAML IDP. End-users are considered Resource Owners. OAuth offers 4 major concepts:

• Grant Types
  
• Client Types
  
• Client Profiles
  
• Application-defined Scopes

More specifically, there are 4 Grant Types:

• Authorization code: client exchanges an authorization code for an access token; this avoids passing the token through the browser where it could be intercepted
  
• Implicit: access token is granted as soon as the user authenticates. This is not as secure and is best for temporary access to non-critical data.
  
• Resource owner password: client uses username and password to obtain access token; this requires a high degree of trust of the client application.
  
• Client credentials: client provides a credential that, due to a configuration step and exchange of something out-of-band, the client can be trusted. A typical example of this is the JWT bearer flow whereby the JWT is signed with a private key, and the public key is uploaded to the authorization server.

There are 3 main client profiles:

• Web application flow
  
• User agent flow (agent is typically a brower)
  
• Native flow (e.g. for mobile applications)
  

OpenID Connect

OpenID Connect is a standard established by the OpenID Foundation. OpenID Connect is a layer on top of OAuth 2.0 that serves to support verifying the identity of an end-user. OpenID Connect defines a JSON Web Token (JWT) security token that makes claims about the Authentication of an End-User by an Authorization Server. OpenID Connect defines 3 types of flows:

• Authorization Code Flow
  
• Implicit Flow
  
• Hybrid Flow
  

The authorization code flow is best for clients that can securely maintain a client secret between themselves and the Authorization Server. The implicit flow is typically implemented by browser-based clients using Javascript. It does not require a separate token endpoint, and so all tokens are returned by the authorization server. This is not as secure as the other flows. The hybrid flow is considered a combination of both prior flows -- in that some tokens are returned by the authorization server and some are returned by the token endpoint. There is also a higher-level login flow, and deep-linking is also supported for this flow. Finally, there are numerous certified open source implementations of OpenID Connect for various programming languages. More information can be found here:

http://openid.net/developers/certified/

Summary

In general, SAML is an older and more heavy-weight approach to authentication -- in the sense that it requires XML parsing and more complexity in the baseline implementation. OAuth 2.0 is lighter weight but does not fully describe end-user identity verification. However, OAuth 2.0 is more foundational because it grants an “access token” that could be used to assert any number of things. In contrast, OpenID Connect is aimed strictly at authentication, and it supports more features with regard to authentication such as dynamic discovery of authentication providers, a login flow, and deep-linking.