At first, this question might initially seem like an apples vs. oranges situation. We’ll find out that in some cases it’s not, and that making the best strategic choice for your needs depends on a number of factors.
Often in enterprise software development and corporate strategy, we take our bag of hammers and perceive everything as a nail. It may be familiarity, perceived cost, or promises of compatibility. These three solutions have different primary use-cases, but we shouldn’t grab one and then throw out the other two choices without considering how they fit into your larger IAM strategy.
For enterprise federation with SaaS platforms, SAML 2.0 via AD FS 3.0 is almost always the proper choice. SAML 2.0 is a very secure protocol, very well supported, and with AD FS present as a Role in Windows Server, the price is “free,” with a very low cost of implementation. Federation via Azure ACS provides a gateway to a large number of SaaS vendors, simplifying the complexity present in one-to-many federation partnerships. (If your organization has to support a federation partnership for each vendor or service, this increases both the complexity and level of effort for support and maintenance. With federation hubs like Azure ACS coming into play, things are much simpler on-premise).
Although Azure Active Directory has OAuth support, on-premise or custom, OAuth integration may be important in realizing the benefit of this protocol. OAuth is widely used and supported in non-enterprise, “Whole Internet” applications. If your organization intends to deploy services accessible by “everyone,” rather than only employees, partners, and vendors, the OAuth strategy merits serious consideration. Likewise if you’re planning to publish a mobile application–for mobile platforms, OAuth is the typical protocol. While we can get SAML 2.0 working with your application as an active user agent, common libraries for OAuth likely make more sense.
You may say “Lee, why do you even mention Workplace Join in this article?” Well, it’s likely that you have users who want to “bring your own device” (BYOD) and still easily access company resources, and files. This option is arguably the least amount of effort. If you only need for non-domain devices to be able to access domain resources for known users, this path is far simpler than the other two. Granted, if you’ve already got AD FS 2.0 or 3.0 in place, we’re going to need to make some configuration changes to support device registration and Workplace Join.
As we’ve seen, implementing OAuth as an authentication interface for non-domain devices and SaaS provided-resources is comparatively complex and requires development. Development will take time and effort. Granted there’s no licensing cost. Furthermore, having OAuth capability can be very valuable, looking forward.
The short of it: For federation with enterprise applications and major SaaS providers, you’re going to be using SAML 2.0. For deployment of mobile applications or Internet applications that need to integrate with sites like Twitter, Google, and Custom Azure applications, you’re going to use OAuth. And if all you need is for BYOD users with iPads, other iOS devices, or users of Windows 8.1 devices to access specific enterprise resources, take a look at implementing Workplace Join.
