Reflecting on 8 Years of Making The Internet a Safer Place
In the late 2000s, I got into the security field while working at a US financial institution. At that time, AWS and cloud computing were brand new — SaaS was just becoming a thing as forward-thinking ASPs and startups were pivoting. Using version 2 of the Web as a platform was still largely a dream of John Battelle and Tim O'Reilly. Back then, web services were built with SOAP or XML-RPC if they weren't still made with DCOM and CORBA 😱. When using the WS-deathstar, the SOAP services were protected using WS-Trust, a complicated protocol that not even vendors implemented correctly. Web sites were secured using WS-Federation. Those fighting on the other side of the Java and .NET war used SAML to protect their websites which, like WS*, included lots of XML signatures, canonicalization, namespaces, and other heavy-handedness. Looking back, I'm shocked that I found this stuff compelling enough to make a career out of it.
I wasn't alone in that feeling. In the early 2010s, the world started to shift toward REST and HATEOAS — now, thankfully, referred to by the much simpler-to-say moniker, hypermedia. It was also around this time that OAuth made its way into the IETF. The first version of this standard was eventually combined with OAuth-WRAP to form OAuth 2.0. The significance of this new spec was quickly apparent to identity experts. It was used to upgrade OpenID 2 to version 3, which goes by the name OpenID Connect. OAuth 2.0 was also used as one of the authentication options in the SCIM protocol we were also working on around that time.
It was now the mid-2010s. Significant momentum toward REST and non-SOAP services could be felt everywhere. We founded Nordic APIs around then to help generate more awareness of APIs and to provide more information about using the Web as a platform. From day one, a key theme at Nordic APIs was security. We dismissed WS-Trust and SAML, knowing from our history that they had no future in API security. Instead, a new collection of protocols was needed that included OAuth and OpenID Connect. We talked about these as the neo-security stack. The problem was that the early implementations of OAuth and OpenID Connect were never going to satisfy all the use cases we saw in the market.
On a long drive, Jacob Ideskog, Curity's CTO, and I were talking about the need for a more technically complete OAuth and OpenID Connect implementation. Jacob had the forethought to realize that what was needed wasn't just better protocol adherence. He had been working in Software Defined Networking (SDN), where the craze at the time was about making network devices "programmable." In SDN, networks use centralized configuration to support dynamic deployments and workloads. As we drove, Jacob explained that enterprise identity software not only failed to implement the extent of the standards but was also static and hard to deploy in a repeatable, predictable way. Before arriving home, we had hatched an idea of how to implement a better mousetrap.
In 2015, we started coding the Curity Identity Server. From day one, it had a central "brain" as you would find in SDN — our "configuration service". This resulted in a product that clearly separated operational data from configuration data. This dichotomy created a clean separation between the different kinds of data in our product, allowing us to rapidly add support for new protocols and features without disrupting the operations of existing customer installations. This meant we could progressively support more and more of the OAuth and OpenID Connect cannon of specifications without fear of breaking live deployments. It is also how we added support for Verifiable Credential Issuance (VCI) in version 8.2 a few weeks ago. This turned out to be our bright idea which is remarkable considering that it was the first idea 😊.
As we continued to code, we needed more help. Simon Andersson, Curity's COO, and I heard a very impactful presentation about recruiting. I remember the speaker quipped that all companies say that people are their most valuable resource, yet few have recruiting processes that ensure that only the best are hired. The presenter showed a video that I'm always reminded of when I think of our recruiting process. It showed a person attempting to walk the keel of a yacht, and the speaker encouraged us to "find people like this who are brave and persistent enough to do amazing things no matter how many times they fail trying!" This approach to hiring has helped us find 40 people who have been able to achieve what most organizations haven't been able to do with 80!
As more people came into the company, it became clear that we all wanted to use our skills to not only make a great product but also to have an impact on the world. Unifying all of us on a single mission was very important to me. It became a simple statement that we often repeat at Curity: We are on a mission to make the internet a safer place. We do this by pouring our expertise, experience, and passion into security software that helps our customers know who is consuming their data and services. This ultimately allows them to determine if access should be allowed or not.
As we approach Curity's 8th birthday on June 10, I am invigorated by telling this short version of our story. It's such a great company with so much potential. The tech and team we've built are world class. With the recent investment we obtained, we will be inviting a lot more people to join us on our journey. With this larger team, we will continue to deliver high-quality products and services that help make the internet safer. If you're interested in being one of those new recruits, please check out our current openings. If you're enthusiastic about the opportunity but don't see something listed that suits you, please contact us and tell us why we should make room on the bus for you!
