Introduction to OAuth 2.0, OpenID Connect, and SCIM

The development of SAML dates from January 2001. As discussed in an earlier post, SAML 2.0 provides a Single Sign On (SSO) authentication and authorization protocol that many view as applicable primarily for federations of enterprises. Mobile applications and dominant Internet applications such as Salesforce, Facebook, Google Apps, Linked In, etc. were providing more or less independent and light-weight “micro-services” fronted by APIs. SAML was deemed too heavy-weight to be supported by such APIs.

By 2014, authentication, authorization, and delegation (of authorized rights) for APIs, are embodied in the standards OAuth, OpenID Connect, and SCIM. These standards call for authentication and access tokens encoded in JavaScript-like Object Notation JSON rather than SAML’s (somewhat more verbose) XML. These JSON tokens are then passed in HTTP headers.

OAuth 2.0 has evolved to be a base technology for authorization, but it’s hard to do authorization without knowing to whom or to what you’re giving rights, and thus authentication sneaks in to the standard. To better address this, OpenID Connect has evolved from earlier versions of OpenID and other security work done by vendors to become a layer on top of OAuth 2.0 for authentication. It would seem that these two standards should merge.

While the proponents of OAuth and OpenID Connect predict that they will eventually supersede SAML, this doesn’t seem likely in the near future as SAML seems to do quite well for enterprises with existing relationships such as supply chains and portals. In addition, there are some use cases where the co-existence of SAML, OAuth, and OpenID Connect seems natural in spite of some duplication of functionality.

Finally SCIM, the System for Cross-domain Identity Management, addresses cross-domain identity management and specifically provides REST APIs for provisioning, change, and de-provisioning, all of which lie outside the realm of OAuth and SAML. SCIM adds considerable complexity to identity management systems, and I’m a little nervous that the initial implementations will have security problems. On the other hand, neglecting these functions is probably worse for security.

My next few IAM posts will discuss the latest versions for each of OAuth, OpenID Connect, and SCIM. I’ll also work an example of co-existence with SAML. The OAuth 2.0 post is next. It is here.

Identity Providers (IdPs) and Identity Management

The identity management problem is complex and getting more and more complex as the Internet evolves. Within a corporation there are multiple users that have multiple roles. Any given user needs to access several public, multi-tenant resources on the Internet, e.g. public clouds, public backup systems, public SaaS applications, and other services. A user most likely has multiple devices from which such access is needed from multiple locations around the world. In addition each individual user may have several security contexts from which authentication is needed; for example, the user’s company, personal use, charitable organization, little league sports team, etc. As we’ve discussed before, a username and password for each combination of device, context, resource is a totally unmanageable situation from many perspectives. Throw in privacy concerns and bad actors who steal and misuse identities, the computing industry has a serious identity problem.

Inside a federation of multiple Service Providers, multiple corporations of users, multiple types of name directories, and multiple Identity Providers, what makes for a good Identity Provider? More generally, in the context of the federation, what makes for a good Identity Management System?

At the highest level, users want unfettered (and secure) access to lots of Service Providers (SPs). When you see a commercial IdP advertised, usually the first marketing statement is the number of “applications” it supports, and of course, there are a few big ones like Saleforce.com, Office 365, and Google Apps that are essential. It is not unusual for an IdP to advertise “thousands” of applications. Some applications want strong authentication, some use only certain protocols or data formats, etc. A user’s corporation may insist on the integration of a particular name service, e.g. Active Directory, LDAP, RADIUS, Tivoli Directory, etc. The IdP is in the middle and must support at least those combinations that the customer needs.

Thus, at the next level, the key things one wants an Identity Provider to do are also listed in the marketing material for various IdPs:

1. Authenticate a user in multiple ways, e.g. extra security questions, hardware frobs, difficult passwords, email, SMS, Telephony, X.509, PIN, Common Access Card (CAC), government Personal Identity Verification (PIV) card, smart card, bio-metric readers, Yubikey, LastPass, KeePass (open-source), etc.
2. Pass this authentication around (“credential mapping”) the federation without having the user re-authenticate unless additional authentication is needed (as opposed to re-authentication); support OpenID Connect, SAML 2.0, WS-Trust Security Token Service (STS), and others
3. Allow service providers to require different levels of authentication based on risk or on the importance of the service: user IP address, IP reputation, group membership, geo location and geo-velocity. Support black and white lists to override risk algorithms
4. Support multiple user devices, incl. Mobile
5. Multiple application types (SaaS, Web, Internal, Mobile, …)
6. Support various name services: AD, LDAP, JDBC, ODBC, Sun One, Novell eDirectory, Tivoli Directory, JBoss Web services, RADIUS, etc.
7. Support Single Sign On (SSO) via SAML 2.0, OpenID Connect, Kerberos Key Distribution Center (KDC), …
8. Security auditing, XDAS
9. Identify anomalous user activity
10. Participate in the enterprise disaster recovery with high redundancy

Some final thoughts about security: Many users, myself included, have been skeptical about the security of an Internet-wide Single Sign On facility. Such a service would be a juicy target for nefarious hackers. Passing around tokens on semi-secure channels appears to invite “pass the hash” and “man in the middle” exploits. The more functionality that an IdP product has, the more opportunity for bugs that open security holes. The more personal identifying information that a product holds, no matter how encrypted, the more inviting a target the IdP becomes. In addition, users should worry about who owns the encryption keys and how they are managed. Some vendors are obtaining security certifications such as SSAE 16, SOC 2 or ISO/IEC 27001. A vendor that gets such a certification is not only thinking about security, it is doing something about it.

My next IAM post is on SAML.  It is here.