<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

Which Federation Protocol Should I Use?

This question comes up frequently when talking to developers in my company. Fortunately MS has a PFE who has blogged on the subject. http://blogs.technet.com/b/askpfeplat/archive/2014/11/03/adfs-deep-dive-comparing-ws-fed-saml-and-oauth-protocols.aspx

This article is fantastic and technically accurate in the details. I highly recommend reading it.  But I disagree with the conclusions he makes at a higher level. I think I can explain that disagreement by examining the PFE’s situation.  Firstly, he wrote this 5 months ago, and the situation changes quickly in federation. Secondly, he works for Microsoft and as a PFE the scenarios he encounters are likely more Microsoft focused than those of us in the “wild”. Thirdly, he is focused on ADFS as his technical area, it is the focus of his blog and he is quite clear on that.  But for those of us using ADFS as a federation infrastructure, many of us are also using Office365 and therefore Azure AD.  So we actually have a secondary federation infrastructure, in Azure AD, available to us. This secondary option changes the landscape by granting us additional federation capabilities because Azure AD iterates more quickly than ADFS. Azure AD supports more types of grant flows in OAuth than ADFS and it supports OpenID Connect.

But back to the conclusions of the blog article. Mr. Gregory concludes that WS-Fed should be chosen for MS centric apps, and SAML should be used for most everything else. OAuth should be used only for Modern/Metro/IOS/Android apps.  And if we focused only on ADFS I would agree with him wholeheartedly. I do not believe he explains those conclusions fully, so I will add my reasoning here.

In our experience WS-Fed can be superior to SAML from the infrastructure side when used with Microsoft centric apps because the updating of the trust and certificates can (not always) be automated. But in general the opinion of many is that the protocols are roughly equal with SAML winning slightly. https://blogs.oracle.com/hubertsblog/entry/deep_dive_on_saml_2 . SAML is ubiquitous and will be supported by most SaaS providers. Most of our trusts are SAML based just because that is what our partners want to use.

Mr. Gregory recommends OAuth only for Modern/Metro/IOS/Android apps. Likely his reason why is explained at this blog article http://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/ . This article explains that SAML does not work well with Mobile apps because the default method that SAML uses to redirect the user from the IDP (after they have logged in and retrieved their claims) back to the Service Provider is the HTTP Redirect method.  This method does not work well with longer messages (such as those with signed claims) so you should use the HTTP Post method instead. The problem is that the mobile apps cannot do that easily, so developers get unhappy.

OAuth on ADFS supports the Authorization Grant Flow with a JSON Web Token (JWT). Mobile apps can accept the JWT easily so developers are happy to use this. The issue is that OAuth is an Authorization (AuthZ) protocol not an Authentication (AuthN) protocol. So if you are just trying to grant access to data in one web service to a another web service and you need a facility to allow the user to authorize that then it is great.  We see this all the time now when one web app wants to access your profile data in Google or Facebook. But OAuth was not designed to authoritatively say Jim Katoe logged in to this IDP and your app should trust this information.  This is in part because the OAuth grant flows do not include digital signing as a requirement. They can be extended to support this, but it is outside of the specification. With OAuth the Service Provider app is basically assuming identity by proving you have access to the account, which is not exactly the same as the IDP authenticating you and verifying cryptographically.

Finally, and not within the capabilities of ADFS, we have OpenID Connect. When using Azure AD, you can use OpenID Connect. OpenID Connect is mobile app friendly and is gaining quickly on SAML. It is also an AuthN protocol. But there have been some public security concerns. http://en.wikipedia.org/wiki/OpenID. OpenID Connect also adds the capability to support consumer identities such as facebook, google, yahoo, microsoft live ID’s. So OpenID Connect has most of the capabilities of SAML/WS-Fed/OAuth and adds some more. It seems like it should be the obvious choice for all new applications. Microsoft is strongly supporting it.

But to use it you need to be comfortable with its security, and you have to be comfortable with the additional complexity and process of Azure AD.  The procedures you have established for ADFS will have to be rewritten, and you will have to figure out how to happily coexist in Azure AD with your developers. Microsoft has not finished their RBAC system for Azure, so that may not be easy. For me personally, I am working on maturing our environment so that we are ready for OpenID Connect and until then we choose from the other three protocols using the reasoning above.  But to be honest the pressure for supporting OpenID Connect is rising.

I hope this was helpful!

Click here to read more blogs by Jim Katoe