_CIOs naturally expect their organizations to make use of cloud applications, and often that means knitting cloud-based applications onto existing on-premise applications. The benefit is that users won’t have to enter more passwords or sign in a second time. The challenge is in choosing an authentication standard for authenticating users to the cloud services.

The Dutch computer scientist Andrew Tanenbaum said, “The nice thing about standards is that you have so many to choose from.” That describes the world of cloud authentication, except that in this case there are also some non-standards in the mix.

When choosing how to manage connections to Cloud-based services, developers have a choice between using actual approved standards (OAuth in particular, but also SAML) or de facto industry standards, which are proprietary specifications pushed by one big company (like Amazon’s Query API).

OAuth and SAML are real standards. However, Amazon’s Query API is not, but it’s how you work with Amazon. Given the range of choice, developers often ask, is it wrong to not use the protocols available? From a pragmatic point of view, can you and your developers for your preferred cloud service providers implement standards across the board? This might take years, and if you wait, you risk losing the advantages of being an early mover in cloud adoption.

More heavyweight applications (as in “SOAP-based”) are typically better suited to the SAML standard, and more lightweight applications (REST-based) are better suited to the OAuth standard. In terms of maturity, SAML is a tried-and-tested standard. SAML is widely used in the mainstream and is broadly supported. For example, it is used by SalesForce.com. However, SAML does not apply comfortably to REST services and APIs.

On the other hand, OAuth, while less mature, is enjoying increasing adoption and is maturing rapidly. It is a more appropriate standard for use with REST services and APIs as it is more lightweight. Additionally, OAuth is easier to bind to lightweight REST APIs, especially with mobile applications.

#!
In the case of Amazon Query API, its REST services are proprietary but are so widely adopted that they can justifiably be called an “industry standard” at this point.

Processing power is another question to consider. Your developers should consider how much horsepower is required to drive specific standards. For example, in the case of SAML, there is heavy XML processing involved, and it also drags in other standards like XML Signature. But with REST-based standards (and non-standards), there are less processing requirements. For example, HMAC signatures (used in the Amazon Query API) are faster at runtime compared to XML signatures with SAML.

Regardless of which standard your developers use, be aware that users perceive the performance of an application as directly linked to quality of service. As such, choosing the correct standard is very important in terms of any business directly servicing consumers. When a user is accessing a business-to-consumer service, performance is most important as the user typically has a negative perception of latency. As such, faster and lighter-weight standards such as OAuth are best used in business-to-consumer scenarios.

However, if your team believes that SAML or Amazon API is more suitable for a particular business-to-consumer setting, select the faster of these two standards because low latency is critical when dealing with consumers.

(Don’t) roll your own
Given the choice and complexity of standards available, it is understandable that your developers may consider developing their own security techniques. Don’t do it! It’s not only extra work, but it’s also a security pitfall because it is always inadvisable to try to generate your own security schemes. Yes, it’s tempting to take what Amazon is doing and make some slight modifications. But please remember that these providers have been through security audits and have developed their specifications with security techniques in mind, so any changes a developer makes is made at their own (or your own) risk.

What about overhead? A cloud service broker can do some of the heavy lifting. Additionally, cloud service brokers are often adopted to speed up the time to market of applications using the cloud, since they offload the work associated with the implementation of standards. The broker translates between the various standards, thus providing larger menus of options to the developer and to users who are consuming the applications. Additionally, if there is a need for dynamic conversion between standards, the broker can easily make this change. In this sense, the broker becomes an application-level router.

Your developers have a complex choice between using actual standards and de facto standards when choosing how to manage connections to cloud-based services. When choosing how to manage connections to cloud-based services, it’s critical to understand how and why specific standards are suitable for particular tasks and when to use them—and when not to use them.

Mark O’Neill is CTO of Vordel, which sells products to manage cloud computing, including a cloud service broker.