Let’s talk about digital identity with Oscar Santolalla, Nat Sakimura and Petteri Stenius.
In this week’s special episode, Oscar explores the history of OpenID Connect and how it became so prevalent, with special guests Nat Sakimura, Chairman at the OpenID Foundation, and Petteri Stenius, Principal Scientist at Ubisecure. Listen to the episode wherever you get your podcasts, or read the transcript below.
“New technology seldomly completely replaces the older technologies. They will form additional layers, and slowly start replacing it.”
Oscar Santolalla: Let’s Talk About Digital Identity, the podcast connecting identity and business. I am your host, Oscar Santolalla.
It was February 2014, already hundreds of millions of people worldwide had a smartphone in their pockets, with dozens of apps installed, apps like: Snapchat, Spotify, Vine, Skype, and games like Angry Birds and Minecraft. Mobile apps had been booming for a few years, and users were eager to install every app that resonated with them out of a seemingly unlimited stream of new apps. Indeed, the Apple’s App Store had recently reached the 1 million mobile apps milestone.
Not only mobile, but also in web services, for every new app I wanted to use, I needed to create a new user account, which was OK when I could count them with my own fingers. But what if I had 20, 30, 40 apps on my phone. This was becoming a headache for people, but especially it was clear to become a security concern.
Identity professionals had seen this challenge even in their own lives. And there were combined efforts from big tech, mobile operators, identity software vendors, to architect a solution. An early effort was the OpenID standard, which gained promising interaction at the start of the 2010s. With my OpenID user account, I could log into Yahoo, Google MySpace, and dozens of thousands of web services. However, the lack of a uniform user experience didn’t help people and not a massive audience got hooked with the standard.
So, what happened after the setback? A new solution had been cooked by identity professionals, and finally solved this long living problem. OpenID Connect not only solved that problem for the big tech and social networks, but created a modern way of user authentication, especially for mobile.
Today, if you are listening to this podcast, you have definitely used OpenID Connect before, with or without knowing it. To hear a story from the brilliant minds that designed this standard, let’s hear from Nat Sakimura, one of the creators of the OpenID Connect 1.0 Standard, and today, Chairman of the OpenID Foundation. How was the world just before OpenID connect appeared?
Nat Sakimura: So you know, the creation of OpenID Connect actually started in 2009. And contemplation on that was actually done from 2007. Even before OpenID 2.0 was published, right? There were things like XRI, XDI, SAML. And SAML was becoming pretty strong in the market, but at the same time, because of the XMLD Signature problems, people are starting to complain about that.
And the OpenID Connect just started off with three people: Me, John Bradley, and Breno De Medeiros at the corner of the Internet Identity Workshop. And we were just sketching out a protocol, which is really dead simple to implement in the simple cases but at the same time, something that could be extended to a very high security, integrity protected federation protocol. And the years between 2010 and 2013 was spent on drafting it and implementing it.
Actually, a lot of people started implementing OpenID Connect back in 2011 or something like that. And we had multiple rounds of interop tests as well as you know, they were actually deployed in the wild and was tested. So OpenID Connect was actually quite well-implemented by service providers like Google before it was published in 2014.
Oscar: Yes, so that was my understanding that before the standard was published, like Google and other service providers already had some version, but not fully compatible. That was my understanding, it’s what I read. So, it then comes…
Nat: Yeah, because it’s… early drafts, right?
Oscar: Exactly, early drafts. So what happened when all these people in these companies decided to join forces to create a unified standard that didn’t exist at that time? Was it easy to reach consensus for creating this new standard?
Nat: So it wasn’t that difficult. So, the process was kind of long, because we had to start from creating the digital signature standard to start with, right, which became JWS. And also, we had to create a token standard, which later became JWT, and encryption as well.
And so we had to start building very basic blocks. In parallel, we were also developing OAuth right, as the base protocol. So it was almost done from the ground up, because we didn’t have enough building blocks. So that kind of took long, but the discussion there wasn’t that contentious, really. People are cooperating and trying to achieve the maximal interoperability and the consensus in good spirit. So that was good.
Oscar: Yeah, that was great. Great to hear that there was consensus already because there was a need for having such a global standard for authentication for these new times especially when mobile was getting big.
Nat: Yeah, I guess the appearance of the iPhone and subsequent mobile-first world actually helped people to converge, because then people realise that they need a new protocol, which could deal with the new environment effectively.
Oscar: Yeah, exactly. And what would have happened if, for some reasons, even though you just told us that it was good consensus, but if some reason the standard had been published but still failed, what would have happened?
Nat: So by the time we have published the final version, it was pretty well deployed. So we didn’t think that it’s going to be a miserable failure. Google, Microsoft, Yahoo – well, at least Yahoo Japan – and a bunch of mobile carriers has already deployed them. So we were quite confident that it is going to achieve some degree of success.
But we actually had a long way to go as well. The specification is written in English – it’s just English, right? And there can be many ways to interpret it. And that became actually blatantly clear. And it was clear that we needed something which makes it tighter. That’s why we created certification suite. And I think over 600 deployments have already tested with the OpenID Connect certification in some form or fashion. And I think that has actually helped the interoperability of OpenID Connect substantially.
Oscar: And when the certification started?
Nat: So that was April 2015, just about a year after we had published OpenID Connect final.
Oscar: OK. OK. Excellent. So it didn’t take too long until…
Nat: Yeah, right. So Google, Microsoft, Ping Identity, ForgeRock, Nomura Research Institute, PayPal, went through the certification.
Oscar: That was Nat Sakimura from the OpenID Foundation. The standard was published and announced in February 2014 during the conferences, RSA 2014 and the Mobile World Congress, and the promise on the press release was “Providing Increased Security, Usability, and Privacy on the Internet”.
I was also curious to get another viewpoint from the early days when OpenID Connect was coming to life. Let’s hear from Petteri Stenius, Principal Scientist at Ubisecure. Since when, you, the team at Ubisecure years ago, start hearing about OpenID Connect? Since when OpenID Connect came to your radar?
Petteri Stenius: All right. Thanks, Oscar. A nice question. Of course, in the very early days Ubisecure was definitely a SAML company. So back in the year of 2008, we had completed a full-matrix interoperability testing with a couple of very large companies like CA, NTT, RSA and Ping. So we had made a huge effort into testing interoperability with our SAML implementation. The testing was quite an effort. It was almost two weeks, a team of four people, when the size of our company was about 20 people at the time.
It was also at that time that we did hear for the first time mentioned the OAuth 1.0 and OpenID 1.0. The names of these protocols started to pop up. Initially, we did look at those, but we didn’t really become interested in the first versions of these protocols. But a couple of years later, the next iterations of this specification started to appear with OAuth 2.0 and OpenID Connect 1.0. We did pay some more attention to this. But we were still quite happy with SAML so we did not rush into any implementations. And I think it was only in 2014, that we started to work on adding support for OAuth 2.0 and OpenID Connect into the products.
Oscar: And that happened, I guess, because some of Ubisecure customers or prospective customers already had new different requirements. So could you tell a bit about that?
Petteri: Yeah. The fact is that SAML is quite complex and it basically requires that you integrate with ready tested implementation. So either your application server has a built-in support for SAML or you add support for SAML with an integration module. So, if you can find an application server that has support for SAML, or you can find an integration module with SAML, then you are quite happy. But the challenge at that time, in the beginning of 2010, 2012, and so, was that people started building web applications with completely new languages, tools and frameworks and application servers. So it was increasingly hard to find integration modules.
Also, there was this boom of mobile apps. So, SAML and mobile apps don’t really work well together. OpenID Connect is better suited for integration with mobile apps. So there was increased demand from our customers that they wanted something that was simpler than SAML and also they had completely new use cases with the mobile apps. So there was good reason to start working on OpenID Connect and OAuth 2.0.
[For more information, check out this blog on the differences between OpenID Connect (OIDC), OAuth 2.0 & SAML]
Oscar: Yeah, exactly. Mobile… well, the explosion of the mobile apps was definitely a driver.
Petteri: Yeah, yeah. It was in the beginning of this decade. Yeah. Last decade, sorry.
Oscar: Yeah. Now, it’s last decade. That’s correct.
Petteri: Yeah. Yeah.
Oscar: And if you can tell us a bit of what happened in the Ubisecure team, development team, when you made the decision already we are going to implement OpenID Connect into the platform. So tell us a bit of how things went in that moment.
Petteri: Yeah. The product from the beginning has been designed so that it’s possible to add support for new federation protocols. There is a plug-in architecture of sorts. So when we started with the product, we only had support for our own in-house ticket protocol – that was in probably 2002 or 2003. Then we soon added SAML and WS-Federation. Initially, adding support for OAuth 2.0 and OpenID Connect was not a huge effort. It was quite straightforward.
But in the end, given all the extensions that have been designed into the specifications, I mean, it has been a significant effort to follow all of the developments in both of these specifications. But I’m fairly happy with the way that it has turned out. We have good support for most of the most important features in both of these specifications. And also we recently were able to complete interoperability testing with OpenID Connect.
Oscar: Yeah, excellent. And I also know that you at some point joined forces in OpenID Foundation. You’re a member and very active member there, right?
Petteri: Yeah, yeah. I’ve been mostly active in the MODRNA Working Group where we are designing APIs for mobile authenticators, because mobile authenticators were… I mean Finland was quite early adopting mobile authenticators with the mobile PKI effort. I think it was already 15 years ago or something like that, that we had the mobile PKI system running in Finland and we had quite a lot of experience from that. And it was good to be sharing those experiences with the MODRNA Working Group and we were designing the new APIs for mobile authenticators.
Oscar: Excellent. Well, it’s great that now we are actively participating also in OpenID Foundation, helping building further this protocol, OpenID Connect and also OAuth 2.0 that evolves in parallel.
That was Petteri Stenius, from Ubisecure.
When the OpenID Connect 1.0 was published, there was a strong need for a standard like that. Big players in tech and in the identity space put in all their efforts, and soon mobile operators, banks, governmental institutions and all kinds of organisations followed the adoption of the standard.
We can certainly say that OpenID Connect took over the world. It’s so prevalent in the online services we use every day that today it’s nearly impossible to measure how many services use the standard.
To give you just one example of the magnitude of this success, at the European Identity and Cloud Conference 2018 in Munich, Alex Simons from Microsoft Identity Division, shared that in the last week of April 2018, 92% of all Azure Active Directory authentication happened with OpenID Connect. That was a massive slice of the pie chart that he showed. And that number is a lot and it’s growing every single day.
Today, nearly every single mobile application in which you authenticate uses the standard. As you can imagine, new security challenges have appeared throughout the years, so the standard had to keep evolving. So I asked Nat Sakimura his thoughts on the future of OpenID Connect.
Let’s now jump to the future, so, if you can tell me a bit of the new things that are happening in OpenID Connect for the protocol and how do you see the future of OpenID Connect if we start thinking five or 10 years, what do you envision?
Nat: Right. So, after we had published OpenID Connect 1.0, we were not standing still. For example, we have done quite a lot of work in the mobile space, as well as mobile operator space, as well as in the Financial Grade API security profile space. So generally speaking, Open Banking. So the UK has adopted FAPI, Australia adopted FAPI, and Brazil is now deploying FAPI into 800 banks and other relying parties there. And the US is also expected to do so pretty soon. And Russia is also in the process of doing so.
So, I continue to see… and so, if you don’t know FAPI is security protocol for higher risk use cases, right? So OpenID Connect can address very simple cases, to high security use cases, and it offers a lot of options. But FAPI actually pins it down to the highest security only options, right? And we do expect more deployments and more adoption of FAPI in the coming years. And in the OpenID Connect working group, we are busily working on something called Self-Issued OpenID Provider or SIOP, which is defined in chapter seven of OpenID Connect Core.
But there are handwavy stuff there. And also, we wanted to make it useful in terms of verified credentials and distributed identifier. So we are making an extension with regard to that. So we expect the specs to be coming out in a year or so, hopefully. So they can be deployed in the self-sovereign and distributed identifier and verified credential space as well. So that’s one thing.
We are also working on something called OpenID Connect for Identity Assurance. And this is to convey metadata about how identity proofing was performed on that particular entity. It’s closely related to GAIN, Global Assured Identity Network, which I announced at EIC last week. And this has been deployed already. And it’s not the final specification, it’s just Implementer’s Draft, but it’s been deployed by multiple parties. And it’s actually actively in use in Europe for creating the qualified certificate and qualified signature. So I’m expecting some take up, at least in this regard, as well. So these are the things coming up.
Oh, there’s another thing. We’re working on something called CAEP, Continuous Access, Evaluation Protocol, and RISC, which is Risk Information Sharing and Coordination protocol. So, we are moving towards the world where just depending on the one authentication event isn’t good enough. We need to evaluate the access continually. And if there are some peculiarities about access, then we might want to notify the stakeholders so that they can be prepared for anomaly and something like that. Or, if it was deemed too low from the point of view of authentication level, then the user can be re-authenticated or something like that.
So, it’s an application of something called security event token. But it’s actually deployed among big techs right now. And I think that’s going to be a very, very useful addition to the world of, I kind of put it, internet security, or cyber world security and safety, let’s say. So these are the things which I do expect to come within five years or so.
Oscar: Yeah, excellent. Excellent. As I can see, there are several improvements and projects also connected to OpenID Connect protocol that come – you’re expecting in five years means – means that in 5, 10 years from now, and even more, we will still be using OpenID Connect.
Nat: In some form or fashion, I think.
Oscar: Yeah, so we’ll see OpenID Connect for many years.
Nat: For example, SAML was published – SAML 2.0 was published in 2005, if my memory serves well, and we are still using it, right? It’s been there for 16 years. So, new technology seldomly completely replaces the older technologies. They will form additional layers, and slowly start replacing it but it doesn’t happen, like at one stroke or something like that.
Oscar: And that was the story of how OpenID Connect took over the world and became an irreplaceable building block for digital identity today. Today, more than 6 billion people use a smartphone, and the most popular apps people use have changed. As Nat Sakimura said, for many years to come, OpenID Connect will be in use, and combined with other standards, will be protecting your identity every time you book a taxi ride, order food delivery, or as this story is coming to an end, go to Netflix and find the next story for your day.
This was a special story episode of Let’s Talk About Digital Identity. Thank you to our guests, Nat Sakimura and Petteri Stenius. The story of this episode was produced by me, Oscar Santolalla, with help of Francesca Hobson and Elena Sanz.
[End of transcript]