Cloud Security Standards


A few months ago at the Cloud Identity Summit (CIS) in London, I gave a presentation on the emerging standards that enable secure access to cloud APIs. The collection of protocols that form the neosecurity stack that I talked about are Simple Cloud Identity Management (SCIM), SAML, OpenID Connect, OAuth 2, and the JSON-based Identity Protocol Suite (JOSE and JWT). These security protocols are quite new (save SAML), and many attendees had not heard of some of them. They are very important for those implementing APIs and SaaS applications though, so I wanted to explain them in a bit more detail.

OpenID Connect and OAuth 2

These two protocols are a really big deal. Together, they provide authentication and delegated access to APIs, respectively.

OpenID Connect is essentially the third version of OpenID. It is a complete rewrite of the protocol and is not compatible with previous versions. It is an HTTP-based protocol that allows apps to authenticate users in foreign security realms. In this way, it provides SSO. Unlike other protocols like SAML and WS-Federation that solve the same problem, OpenID Connect provides the following unique benefits and features:

  • Built atop OAuth 2 which is much simpler to implement than prior versions of that spec
  • Designed with native mobile apps and HTML 5 Web apps in mind
  • Designed to achieve higher Levels of Assurance (LoA)
  • RESTful in nature, providing all the benefits of that modern design paradigm
  • Low tech barrier that requires little more than HTTP and JSON support

For more info on OpenID Connect, see the OpenID Foundation's Web site. We'll be blogging about the importance and benefits of OAuth 2 in some of our upcoming posts. Connect on Twitter if you are curious before then.


In early 2011, a bunch of us from Salesforce, Cisco, Google, UnboundID, Ping Identity, and others came together to define a new protocol to manage user accounts and groups in the cloud. The intention was to create a spec that harmonized the various APIs that the big SaaS vendors had for this purpose. To increase interop, a standardized user schema was defined in addition to an API. Using various models from prior art like inetOrgPerson and Portable Contacts (PoCo), we came up with a normalized set of user attributes and a simple way of grouping them together.

In about a year, we defined the spec, iterated over it in an open forum, performed two interop events w/ a dozen or so participants, and submitted the resulting work to the IETF for further development. The result was a spec that included these features:

  • A Well defined user attributes that helped ensure interop
  • A provisioning API to manage users and groups
  • Bulk updates for ingest & synchronization
  • Very low technology barrier, requiring no more than what's available in JavaScript or cURL
  • Works hand-in-glove w/ federation for Just-in-Tme (JIT) provisioning via SAML, OpenID Connect, and other Web SSO protocols
  • API calls can be secured with OAuth 2 or other HTTP authentication schemes

In the absence of a modern alternative that is as simple and narrow in focus coupled w/ the great need for account management to secure the cloud, SCIM is a protocol that will only continue to see more uptake.

JSON-based Identity Protocol Suite

JavaScript Object Notation (JSON) is a data encoding format that has been popularized by AJAX and REST. This serialization format is being used to define a new security model for OAuth 2. In the IETF and the OpenID Foundation, the authors are using the JSON data format to define new ways to encode tokens, symmetric and asymmetric keys, encryption algorithms, and digital signatures which work hand in hand w/ OAuth 2 and OpenID Connect. Tokens encoding in this JavaScript format are being defined in the JSON Web Token (JWT) spec, pronounced "jot." These are lightweight tokens that can easily be passed in HTTP headers and query strings. They are akin to SAML tokens except that they are less expressive, include less security options, and are of course encoded w/ JSON not XML for the sake of compactness. The key-related spec I mentioned is called JSON Web Key (JWK), and is used to encode an array of keys as JSON objects. Digital signature that are encoded in JavaScript are being defined in the JSON Web Signature (JWS) spec. This protocol defines a way to symmetrically and asymmetrically produce dsigs that are included in JWTs.

These protocols are still in active development, but there are already shipping products that use them and libraries available that make it easy to work w/ them.


SAML is a proven and trustworthy spec that can do the things that OpenID Connect will do in time. I believe OpenID Connect will eventually become as trusted as SAML is today and will replace it for most deployments. It's like Patrick Harding, Ping Identity's CTO said in Vail a couple weeks ago: SAML is a distinguished gentlemen and OpenID Connect is the up-and-coming youngster that will hopefully follow in his footsteps. Till that day, however, use the established federation protocol, looking to the upstart as a newer alternative that might be a better fit.


As you have read, there are a lot of new specs coming down the pike. These are important developments that cloud adopters need to learn about and support. Whether you are exposing a new API, launching a cloud service, or setting up a Web site, it is likely that you'll need some or all of the capabilities provided by these protocols. It can be hard to keep on top of all them all though. At Twobo, Identity and Access Management (IAM) is our passion, and we are happy to read through all these specs word for word. With this know-how, we can help you translate them into interesting and useful products. If you'd like help in this regard, please let us know by leaving a comment here, contacting us, or snagging us on Twitter.