The death (and life) of a protocol

31.07.2012 by Dave Kearns

I had a great time at the recent Cloud Identity Summit – a fantastic venue (Vail, CO) with a wonderful lineup of speakers second only to our own European Identity and Cloud Conference (EIC) coming up next May in Munich. (Hurry, the call for speakers is already underway).

What I didn’t expect in Vail was a great deal of controversy, but there was. And right at the center of it all was my colleague, KuppingerCole’s Distinguished Analyst Craig Burton. Craig stood up at the podium and announced to the world: “SAML is dead.”

This was off the chart because, well, SAML (Security Assertion Markup Language) is at the heart of most of Ping Identity’s products. And Ping Identity was our host. Predictably, Ping employee tweets immediately sought to reassure their followers that SAML was alive and well. What they neglected to take into account, though, was context.

Context is important for Identity Services as I’ve said over and over again for at least 10 years (see “Identity and privacy: it’s all about context”). But context is also important for understanding the spoken word.

Craig was speaking in a track I was moderating called “Analyst Perspectives,” and the title of his presentation was “The Future of Authentication.” Note that word “Future”.

Most of the other analysts agreed with Craig (as did many of the attendees, especially those who were in his audience.) Some pointed out that other, seemingly dead, authentication protocols (such as IBM’s RACF and Top-Secret) were still used by many as were programs written in COBOL.

But far from being an argument against Burton’s pronouncement these are actually supporting evidence for his claim that SAML is dead. Because RACF and COBOL are also “dead,” at least in the sense Craig meant.

Remember, he was speaking about the future of authentication, not the situation today. He was warning those just starting out on the road to replacing username/password combinations for login, to those looking to create tomorrow’s Simplified Signon (SSO) solution or those needing to plan for cloud-based services (including authentication) in the future that SAML should not be the primary conduit for their data.

As he qualified his remarks, Burton said: “SAML is the Windows XP of Identity. No funding. No innovation. People still use it. But it has no future.” And added, “There is no future for SAML. No one is putting money into SAML development. NO ONE is writing new SAML code. SAML is dead.”

And then he reiterated for the hard of understanding: “SAML is dead does not mean SAML is bad. SAML is dead does not mean SAML isn’t useful. SAML is dead means SAML is not the future.”

So what is the future for authentication?

In May, at EIC I presented an award: Best New Standard 2012 in the Category “Best Innovation/New Standard in Information Security” which went to OpenID Connect for “Providing the Consumerization of SAML. Driving the adoption of federation and making this much simpler.”

As we said at that time:

“OpenID Connect is a simple JSON/REST-based interoperable identity protocol built on top of the OAuth 2.0 family of specifications. Its design philosophy is “make simple things simple and make complicated things possible”.

While OAuth 2.0 is a generic access authorization delegation protocol, thus enabling the transfer of arbitrary data, it does not define ways to authenticate users or communicate information about them. OpenID Connect provides a secure, flexible, and interoperable identity layer on top of OAuth 2.0 so that digital identities can be easily used across sites and applications. While enabling a default set of common claims about the user (such as name, e-mail address, and a user identifier enabling SSO) to be easily employed, OpenID Connect also enables participants to exchange any claims relevant to their application using simple JSON-based data structures.

As it is based in OAuth 2.0, OpenID Connect reaches beyond the Web. OpenID Connect brings identity interactions to “apps” and “native applications” on both smart phones and traditional computing devices, in addition to Web sites.”

OpenID Connect is many things that SAML isn’t: simple to implement, easy to maintain, efficient for all parties but especially at scale. Long after a pure SAML environment becomes hopelessly inefficient because it’s an inherently point-to-point protocol, OpenID Connect continues to hum along.

Other issues we addressed include –

  • From a security perspective, OpenID Connect was built to be able to gracefully range from the low security levels typically employed for social networks to medium security levels needed for business applications to high security requirements needed for many government applications. OpenID Connect spans this wide range of applications by using JSON-based digital signature and encryption standards.
  • From a privacy perspective, OpenID Connect allows the selective sharing of attributes with user consent. It also enables the use of pairwise pseudonymous identifiers, thereby avoiding correlations as appropriate.
  • From a business perspective, OpenID Connect meets business needs for the use of claims from multiple Claims Providers in a single context (rather than a single Identity Provider being the source of all claims for any given interaction). It enables the use of Aggregated Claims, where signed claim values can be collected and passed on by OpenID Providers and the use of Distributed Claims, where claims are passed by reference, rather than by value, and dynamically retrieved by Relying Parties.

OpenID Connect is RESTful, SAML requires SOAP. OpenID Connect is represented in JSON, SAML is – of course – an XML subset.  Both of these mean that OpenID Connect is a leaner, more efficient protocol. But here’s the capper: OpenID Connect can be bound to SAML. The path to transition is very clear.

As I was writing this, the long-time lead author of Oauth, Eran Hammer-Lahav, posted to his blog that he was – effectively immediately – resigning that role. His reasons all really boil down to this: “At the core of the problem is the strong and unbridgeable conflict between the web and the enterprise worlds.” Like many designed-for-the-web (or “user centric” or “consumer centric”) identity protocols, Oauth 1.0 was very lean, very easy to implement – and very easy to get wrong. It did what the designers intended it to do, but – like OpenID 1.0, or SCIM 1.0 – it was far from robust, far from secure and far from satisfying the needs of Identity Management. I’ve no problem leaving Oauth 1.x and/or OpenID 1.x to be used for their initially intended purposes (SSO for low value web sites). But the needs of the enterprise are also important, and the improved versions of these protocols – OpenID Connect and Oauth 2.0 – are the future.

SAML was king, at least in the opening decade of the 21st century, but the king is dead. Long live the king!

  • @mrtopf

    Well, once upon a time OpenID Connect was simple, even OAuth 2.0. Now both are monsters. This might be the future in the enterprise world but not for the web. We need simple otherwise nobody is going to implement it. We don't want to earn money by being the few ones actually understanding the auth layer. We want to build things. So OpenID Connectin and OAuth 2.0 do not look like the future to me, except if nobody comes up with something different.

    My fear is more that this actually is a set back for interop on the web as it's maybe easier now for providers like facebook to simply provider their own propietary solution (like they did with the graph api. Very simple, very powerful but not standardized in any way).

    • dickhardt

      @mrtopf: Facebook Connect is pretty much OAuth 2.0 and it is drammatically simpler to authenticate against FB's API than Twitter's API (which uses OAuth 1.0).

      I agree that the OAuth 2.0 specs have gotten bloated — the past editor did not do a good job of keeping the specification simple, and did not like bearer tokens, so forced that simple part of the spec into a separate document. I would agree with you that OpenID Connect is pretty complicated for what it does.

      • @_nat_en

        I would agree on OAuth 2.0.

        OpenID Connect Basic Client Profile is dead simple. I would welcome further editorial simplification suggestion.

        True, the full spec is more complex but that is for distributed attribute networks and the high assurance use cases.
        They still are relatively simple to solve those problems.

  • @_nat_en

    @mrtopf Have you really read the specs? Have you implemented them?

    OAuth 2.0 is simpler than OAuth 1.0 to implement.

    OpenID Connect is dead simple in the basic cases.
    It was possible only because of OAuth 2.0. If it were to be based on OAuth 1.0, it would have become much more complex as well as less secure and scalable in the higher assurance cases.

    • @mrtopf

      Yes, I implemented OAuth 2.0 for e.g. Facebook or some UMA prototype. It's easier than 1.0, sure but still the spec grew and grew and grew when I wondered why it's not long finished. Now I learn it's still not finished

      Similar with OpenID Connect. I once remembered it from back then when it was one page and easy to understand. I wanted to implement it some time late and found several specs where I had not idea how they actually belong together and where to start. And now you also have this architecture overview on the page with all those boxes. Both stand to me for "I am a very complex thing". So it might be easy but it's not obvious.

      So in both cases too many use cases have been put into it. This does not make for simple though (I had the same feeling with UMA when I was still active there but cannot really say as I haven't looked at it in a while). So why not go back to one of the first versions, fix some bugs and put all the rest in some separate enterprise spec with a different name?

      Back then when I still was active I wanted to bring simple to the enterprise but instead it seemed to have gone the other way round. Too bad.

      • @_nat

        From outside, it looks like the draft went to RFC editor almost immediately after the editor left.

        As to the OpenID Connect is concerned, 1 pager by David is not a spec. It is a sketch.
        A comparable one is the blog post I quoted above. Did you read it?

        As to the spec., just read the Basic Client Profile unless you are building an IdP.

        I got your message that the box diagram is not working.
        I will relay that message to the author of the diagram.

  • Pingback: SAML joins the IT zombie legions? « Identity Sander()

  • @nicoleharris

    As an analyst, Burton really should have done a better job with his homework. The Shibboleth community is still developing SAML code, and is very actively attracting new funding at the moment. SimpleSAMLphp is actively developing code and have recently taken on new coders so clearly have funders. At the moment there are over 15 million users taking advantage of SAML based identity federations in education and research worldwide. SAML and OAuth are different beasts, can exist quite happily in the world together and increased usage of OAuth – which I'd be happy to see – does not mean that SAML is suddenly and arbitrarily dead. A little less hype and a little more fact based research would be welcomed here.

    • @_nat

      I actually have filed a grant request to improve Shibboleth today. Hopefully we will get it to further develop SAML related things.So, clearly, there are some funding streams there towards SAML. The grant request I filed is related to an academic network.

      What Craig pointed out however is the funding for commercial implementations, I guess.

    • Dave Kearns

      Perhaps if you read – and uderstood – what was said and what was written you wouldn't write such nonesense as "SAML is suddenly and arbitrarily dead". No one said that, it's a straw man argument. The thesis is that future development of and with SAML is nt recommended.

  • Chuck Mortimore

    As a platform with investments in OAuth, OpenID Connect, and SAML, we still see plenty of investment and innovation going into SAML. We just added a number of features for our winter release to our SAML IDP. The transition from on-premise to cloud IDM is forcing similar investments across the Identity platforms and startups in this space. Just-in-time provisioning is increasingly popular. New toolkits have been developed to enable SPs in languages like ruby + python ( ). Salesforce and Box have both developed new patterns for layering SAML and OAuth to for SAML on mobile devices (… ) OAuth has new SAML Assertion flows for API clients as well. (… )

    Not sexy, but SAML is still the grand-daddy and still getting investment.

  • Per Hägerö

    I would agree with Chuck, there is still a lot of investment in SAML both at the IdP and SP side, we see a lot of customers interest in expanding their SAML deployments. In addition we expect increased interest in Auth 2.0, OpenID Connect, UMA etc very soon but customers will expect that this can be used in coexistence with SAML.

    • Dave Kearns

      And, again, we were talking about customers installing what the need for today, but about the future. And the future isn't SAML.

      • Dave Kearns

        That is, we were NOT talking about what customers are istalling today…

  • Rainer Hörbe

    Craig said in Vail (see that federation does not scale in the API economy because it deploys a 1:1 relationship, and we need to move to a hybrid cloudy model. Then he jumps to the conclusion that SAML == Federation, hence SAML does not scale, and underlies this with an enterprise-type scenario.
    Besides his unorthodox use of the term Federation this is ignoring a number of facts:
    – There are well-oiled implementations of SAML in federations across security domains. They prove SAML has no restriction re multi-centricity and multi-lateral trust relationships; Definitely SAML does not require a centralized model;
    – The technical protocol is in my view less important than its business context, like the ecosystem and the cost to set up a relationship;
    – XML and SOAP might be gossipy, but with API packaging and on-the-wire compression this is a minor issue. ASN.1 and X.509 have their ugly faces, too, and we are still bootstrapping most of our "real" security based on them.

    Confederation would be a better term to describe identity federations, but that horse is out of the barn.

  • Hannes Tschofenig

    A comment regarding the statement from @mrtopf: "We need simple otherwise nobody is going to implement it."

    Did you notice that there are many OAuth 2.0 libraries?

    Ideally, I would like Web application developers to use libraries and not implement these security protocols themselves. They will for sure get it wrong. Look at TLS: many very good libraries, used everywhere, and no normal application developer would even try to write their own TLS stack.

    I would also encourage you to have a look at the OAuth 2.0 specification and to tell us on the mailing list what you think is complex. Everyone can join the list and provide their feedback. Have you done that? If you don't participate in the work you cannot hardly complain about the result. Look at the mailing list how the decisions were made and what issues got discussed. Here is the pointer:

  • Martin Kuppinger

    I think it is really worth to look at both what Craig said in Vail and what Dave has written EXACTLY. Both didn't say that SAML will immediately disappear. There is value in SAML. But the future is different from SAML, because SAML is too limited for what we need not only in future, but what we need today. So SAML is moving towards a "legacy status". And Craig is right here. So I think as an analyst he has done an excellent job with his homework here.
    If we look at the future, we are seeing some fundamental changes. We will see (and are seeing) authorizations relying on different "claims" provided by different parties, with different authentication. That is not the type of relation SAML was built for. And that's what Craig has said: Facing the current and future requirements, things are moving from very clearly defined relationships between IdPs and SPs towards a mesh of such relations. And these can't be efficiently handled by today's SAML protocol. SAML will play its role in several use cases but it isn't the future.
    Have a look at – we will publísh Craig's new report "The Future of Authentication" within the next few days.

  • Pingback: SAML Sets Sail | Risk Horizon Blog()

  • Brian Campbell


    Can you explain what you mean by a "point-to-point protocol?" What about SAML is inherently so? And what about Connect is different in that respect?

    I'm not trying to pick a fight, BTW, I'm developing some training/presentation content on JOSE, JWT and Connect and much of it is in contrast to SAML (in fact, Craig's pronouncement is used to set up the whole thing and I cite this post a couple times). I wanted to discuss this idea of point-to-pointness because it strikes me as important but as I started to do so, I realized I don't fully understand what you mean by it. And that makes it hard to agree or (preferably) disagree with you.


  • Pingback: What We Mean By Federated Identity & What It Means To You-2 | SmartSignin()

  • Pingback: What We Mean By Federated Identity & What It Means To You-2 | SmartSignin()

  • Pingback: What We Mean By Federated Identity & What It Means To You-2 | SmartSignin()

  • utah seo

    Plus his irregular utilization of the term Federation this is disregarding various actualities:

    – There are decently oiled usage of SAML in organizations crosswise over security spaces. They demonstrate SAML has no confinement re multi-centricity and multi-sidelong trust connections; Definitely SAML does not oblige a concentrated model;

    – The specialized convention is in my view less vital than its business setting, in the same way as the biological community and the expense to set up a relationship;

    – XML and SOAP could be gossipy, however with API bundling and on-the-wire pressure this is a minor issue. Asn.1 and X.509 have their monstrous confronts, too, and we are as of now bootstrapping a large portion of our "genuine" security dependent upon them.

  • Brian Campbell

    I work right on the margins of this new vs old protocol and can say that, at least right now, there's investment and innovation happening with both.

    One area that I do have a lot of optimism about is in some of the underpinnings to Connect – JOSE (JWS, JWE and JWK) as well as JWT really have built on the lessons of the past and will be a simpler, more compact and more secure way to produce and consume tokens and to exchange keys. I've developed an open source implementation of much of that stack, which can be found at

    It's not comment spam, if it's actually related to the topic right? :)

© 2015 Dave Kearns, KuppingerCole