OpenAI, Google, and How Access Concerns Changes With Scale

Earlier this November, the OpenAI foundation announced that DALL-E, its popular AI image generation tool, now had an API.

An API's access scheme can tell a lot about the API designer's maturity, intended audience, and long-term ambition. The conceptual part of various approaches, fascinates me more than the mechanical instrumentation. In this edition of Net API Notes, let's unpack API access, from most straightforward implementation to Google scale, and note the lessons along the way. Then I'll wrap it with what OpenAI's API access signals to me.

API ACCESS LEVEL 0: FREE FOR ALL

While much rarer these days, I occasionally see APIs with no authentication requirement for usage. I'm not just talking about hobby toys people spin up on the weekend. DeepAI.org is another organization with a text-to-image generation API, and it can be hit immediately via curl statement or Postman request. (Technically, DeepAI.org's API does require a custom "api-key" header value. However, the quickstart key provided in their API docs has worked with my daily automated processes for several months without incident. There is a key, but much like APIs that do not require a key, they have no idea who I am and would be hard-pressed to modify my access without potentially impacting others.)

Not limiting access (or, in DeepAI's case, giving everybody a key) is the quickest form of Time-To-First Hello-World.)

However, as Australian security consultant and author of Have I Been Pwned's Troy Hunt discovered, no good intention goes unpunished. As he documented in his 2019 blog post, no amount of savvy firewall rules or user-agent regex can effectively rate-limit bad actors on an open API. And, unfortunately, without any kind of access regulating mechanism, the bandwidth and compute consumed by the bad actors negatively impacts legitimate users.

API ACCESS LEVEL 1: KEYS UNLOCK DOORS

To combat these problems, many API providers introduce a rudimentary exchange: give us, the provider, some contact information, we'll provide you with your unique key to be used when making a request. When the provider receives this key they ensure everyone is still playing nice and then "do the needful".

There are now some additional steps to TTFHW in this scheme. However, the concept of passing a key is still pretty simple, and we've been doing this long enough that most API consumers grok this quickly enough.

Sometimes I still see APIs allowing the key to be passed as a query parameter. I get that this makes copying and pasting simple, but it makes me whince. Any web infrastructure between the API caller and provider is probably logging, at minimum, URLs. This means the key is now copied into who-knows-how-many intermediaries and their log storage.

And requiring the key to be included as part of the body request, even when using the GET method, tells me this is your first API.

It is better form to pass keys in a header value. Yes, it does mean an extra Google for the curl header syntax. But if it keeps keys out of log files and doesn't violate well-understood protocol convention, the momentary ding to one's geek pride is worth it.

Officially, the key should be in the HTTP Authorization header, according to RFC7235. However, in practice, there are as many bespoke implementations of passing an API key via the header as snowflakes in my Minnesota backyard. Darrell Miller wrote, perhaps, the definitive piece on this back in 2014.

The API provider gains several benefits from this approach.

• Traffic is no longer anonymous. API keys identify an application's traffic for the API producer, enabling one to debug an issue or show their application's usage
• Rate limiting
• Identify usage patterns, including new and novel usages
• Additional log filtering options, like by API key

In addition, we now have a product relationship. When there are changes, like a new version, the API provider can contact the consumers.

This relationship is brittle, though. It connects one API to one registered account. My Pinboard API key is for the Pinboard service. Access to DraftIn, my online markdown editor, is for the entire DraftIn API. What happens if an API provider has several APIs? Does a single registration and key provide access to all APIs? And how does an API consuming company manage access if keys are associated with an individual?

Note: I'm bypassing schemes, like OAuth 2.0, which exchange a key for a token to be associated with subsequent requests. While passing tokens rather than keys provides an additional control point in the authentication life cycle, after the initial handshake and credential swap, the result is much as before. I want to get to what really changes with scale.

API ACCESS LEVEL X - BRING FORTH THE BOUNDARIES!

Very few of us work alone. People join teams, teams have projects, departments manage projects, and departments roll up to organizations. We need structure to reflect these arrangements (and how they share information) with our API access.

At the same time, companies who once exposed "the API" may now have several offerings. They need to introduce centralized registration, team administration management, and mechanisms for service discovery.

On their own, these abstract concepts are grokkable. However, aggregated together, they can create comprehension challenges for API consumers used to services like OpenAI, where there is a direct relationship between registration and service access. To illustrate the point and the Matryoshka Doll-like nesting concepts, I want to talk about Google.

Few companies operate at a greater scale than Google. Many of their APIs - like the ones for Maps, Google Drive, or AdSense - are category leaders. To use one of these APIs, the first mental shift a consumer needs to make is not to begin by registering for access to the desired API. The first step is accessing what relationship the consumer has with Google. If the consumer is part of an organization with an existing Google Cloud account, there is one path. It requires understanding the organization's configuration of folders, projects, and resources. Knowing where to stand up a new project, what naming conventions are expected, and to whom to route requests are all prerequisites to getting access credentials.

Those operating outside of an existing organization have a forked experience. With a valid Google account, they can sign up for Google Cloud and receive $300 in credit for trying things out. Going this route, some abstractions, like organization management and nested folders, are either hidden or de-emphasized. Prospective API consumers still need to comprehend creating a project prerequisite before even searching for an API. Further, APIs are just one of many possible "resources" that can be added to a project.

Again, not impossible. But there is the imposition of making a variety of decisions about interface comprehension, project organization, and even architectural decisions before I can access the API itself.

1. Start with a Google Account; create one if you don't have one.
2. Don't sign up with the API, but with the Google Cloud Platform; this includes entering credit card details even if you're sure you're staying within your $300 credit.
3. Create a new Project, since APIs are resources, and resources must be added to Projects; while the interface makes mention of a parent organization, ignore it as it can't be changed.
4. Search the API catalog for the API to be used.
5. Enable an API - this will add it to a project but does not create credentials. These are two different steps.
6. Different APIs have different access mechanisms. After enabling the API, generating credentials requires following the appropriate process for that API, a process which may introduce new concepts like 'Apps' or 'Service Accounts'.

This route attempts to streamline many of the possible concepts. But, when performing this process myself, I'm struck by all the places where the water clears, and I can see the complexity lurking just beneath the surface. Whether that's forking access patterns if I'm using App Engine, read-only dialog boxes for organization values I can't change, or documentation referencing the full-blown organizational UI when I'm in the solo, tire-kicking phase.

There's long-term benefit to all that. If my idea grows, I have plenty of malleability to introduce boundaries that match my organizational structure. At this moment, however, to use Google's address validation, I'm again appending an API key to the end of a URL in Postman:

https://maps.googleapis.com/maps/api/place/details/json?fields=rating&place_id=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY

<rimshot>

BACK TO OPENAI'S NEW API

So, all that said, what does OpenAI's API tell us about their future direction? For starters, their access is that tight coupling between an individual's account and the API synonymous with the company. As the list of example usage grows, it may be desirable to begin grouping similar items in their APIs (with their pricing models, rate limits, etc.); code language services like converting JavaScript to Python or Python bug fixing seem like very different use cases than extracting keywords or grammar creation.

Also, having a single individual with the sole key is a single point of failure. If Gary signs up with OpenAI and wires it into the native app, what happens when Gary leaves the company? Is everyone just sharing Gary's credentials?

In early 2020, I predicted the AI APIs were coming. Tools like OpenAI's API continue to increase access for a larger audience. However, at least initially, their access pattern indicates they're still attempting to reach individual hobbyists, not larger organizations.

MILESTONES

• Twitter has been a significant piece of my career for the past 15 years. I've had great conversations, made friends, and discovered professional opportunities there. My Twitter handle has been nearly synonymous with me, appearing in my presentations and email signatures. However, it's time to move on. In my Better Bits newsletter, I wrote about how the change tactics displayed are the antithesis of what we need more of in the world. (The whole turning off random microservices was maybe the least shocking thing that has transpired over the past three weeks). For those interested, you can now find me on Mastodon.
• A few issues ago, I wrote about how Github's Copilot could be used to generate OpenAPI descriptions. A topic I skirted was the legality of training a bot on others' code, even if that code is publicly accessible. Copilot's creators have now been the target of a class-action lawsuit. It looks like we'll find out.
• Security Researcher Troy Hunt, mentioned above, continues to expand and share his 'Have I Been Pwned API' experience. In his write-up, Troy covers what it is like to integrate the Stripe API.
• There's new Gartner guidance that suggests Robotic Process Automation (or RPA) should only be attempted when other API approaches have been exhausted (paywalled, unfortunately).

WRAPPING UP

First off, I need to thank the handful of folks that I talked with about various aspects of this article. There were lots of potential rabbit holes I could have disappeared into and I appreciate everyone’s help keeping things at the right level.

Also, thank you to my Patrons! These are the people that keep these emails free of ads, paywalls, or information. If you're interested in joining them, go to my Patron page.

That's all for now. Till next time,

Matthew

@matthewreinbold

matthewreinbold.com