The Power and Responsibility of your API
While the internet lights up with terrifying costume ideas every October, what we find truly scary are the security breaches that have hit major companies in recent months. Luckily, we have National Cybersecurity Awareness month to provide focus and resources toward a safe and secure internet. To celebrate and observe the month, our diverse team of security thought leaders will present ideas, opinions and best practices around security.
Week three brings you resident API Problem Solver Keith Casey who, through a series of blogs and resources, will take you through a natural history of the API: where it came from, where it’s been and where it (should) go.
My everyday career goal is to get good technology into the hands of good people to do great things; APIs are a perfect mechanism to do that, making it easier and faster to build powerful applications that meet customers when and where they need it. But with great power comes great responsibility and unfortunately, our security mindset and practices around APIs haven’t adapted to these new approaches. The result has been massive breaches of personal financial data, company trade secrets, and probably more we have yet to imagine.
I’ve spent the last few years or so thinking about this and approaching it from a variety of angles in my day job, side projects, and at conferences all over. The following lines–spanning the Okta blogs, my personal site, and a few slide decks–capture these ideas. This collection will step you through my thoughts on the API journey, and where we should go from here.
A short history of the API
As we design and build APIs, it all begins from developer experience and documentation. I firmly believe that if we write documentation, build SDKs, and design examples demonstrating good practices from the beginning, it sets the tone for everything else. Check out my personal site to read the case for developer experience and my mindset on how to document APIs The Right Way.
In May, I shifted into how APIs became important in the first place and how they grow throughout an organization. While we understand this from a development perspective, in Security and the API Journey I try to approach it from the organization’s point of view.
Where we are
At present, making API security better has to be a two-prong approach.
First, we have to acknowledge that we’re under attack. In (Mis)Using APIs for Fun & Profit, I take a darker look at what malicious users are already accomplishing with our APIs and a few approaches to clean it up. If you want the read about the same fixes and still sleep at night, API Security in the Wild is a more hopeful explanation.
Taking this idea further, most of our biggest security problems begin at the beginning with poor designs and incomplete or flawed implementations. The best approach here is to understand our tools. In Understanding OAuth 2.0 and OpenID Connect and in my Many Layers of OAuth presentation, I cover what OAuth is, what it isn’t, and where it shines. But when in doubt, the book OAuth 2.0 Simplified is my go to reference for everything OAuth 2.
My colleague Tom Smith took this a step further and integrated it into an API gateway in Secure Your API with OAuth, Mulesoft, and Okta in 20 Minutes. This was so useful that Apigee, Kong, and other gateways are next on our list. Stay tuned there.
Another helpful spot from the Okta Developer blog is A Guide to Building and Securing APIs, a detailed teardown of security throughout the API stack written by the combined efforts of our Developer Relations team. With a variety of perspectives and backgrounds, it’s a great read but will make you ask more questions than it can answer.
Where we should go
So, given these realities, where should we be going? Anyone building or managing an API should be digging deep on proper usage based on the OAuth 2.0 specifications, relevant design decisions, and security best practices, but that is a ton of work and easy to make mistakes. On the Okta side of things, I’ve worked with a number of sales engineers, customers, partners, opinionated smart people, and others distilling our lessons learned into our guide Recommended Practices for API Access Management. While it is based on our API Access Management product, the vast majority of it is applicable to anyone using OAuth 2.0 in their API. Even if you’re not using us, consider the points carefully.
