The author offers no evidence for the claim that API management and security solutions are needlessly complex in order to create more business for themselves. I think it's much more likely that API management and security software has grown to address the more complex needs of the APIs they serve. It isn't 2010 anymore - handing out plaintext API keys that never expire isn't good enough for many products, and features like RBAC and IAM have become more necessary as more people use APIs to do more stuff.
Now let me go remind myself how OAuth works again...
I think OAuth is a good example of exactly what the article author is saying.
Using OAuth 2.0 isn't very hard at all.
You make some straight forward HTTP calls, and potentially show a browser and get a code by listening to a HTTP request depending on flow.
Then you take the token and pass it in a regular HTTP header.
It's not hard at all. What is hard is the things the article author mentions.
The technical language around it if you're new to OAuth. Figuring out how it maps to the libraries like the one you linked to. Figuring out how to register your app with the provider if you haven't done it before.
I had to implement my own OAuth 2.0 library, and once I had grokked all the things the author mentions, actually using the OAuth 2.0 endpoints wasn't hard at all.
> Doing an OAuth dance that requires 5 steps in the best case
No, in best case it requires one simple HTTP call[1] to an OAuth endpoint, and passing what you get back in the same HTTP header you'd use for username and password.
Sure some flows have more steps, but then they provide significantly more feature-wise than a simple username and password.
The actual "song and dance" is certainly not very complex, relative to a lot of other things we do in programming. It involves some steps, but not that many, and the steps are mostly well-known stuff, ie making or receiving HTTP requests.
Now if you add OICD[2] on top, the sure then that can add complexity.
Again most of it is in the technical language and tooling etc, ie now you might need to create a JWT token, sign it, maybe include the certificate chain etc.
Just knowing what is OAuth vs OAuth2 vs OIDC is a nightmare on itself - and even when you know, you don't really know or know what is actually deployed/implemented and what "flow" (wtf?) was used. The whole ecosystem suffers from buzzword's being thrown around with everyone having a kinda / maybe / dangerous level of understanding of them. Just the other day I had to remind myself the difference between a "login" token and a "refresh" token, which are completely reversed from what most would assume just by reading the words.
And even then, short of looking up the actual papers/specs for OAuth(2)/OIDC, I still have this nagging feeling at the back of my head that I am getting something wrong wrt the naming of the tokens.
Sure, and as I said that's what I agree with the author on in this case.
The hard part isn't the actual API calls, it's all the jargon and such around them as you say.
In contrast, take something like say Vulkan. That's an API I'd consider to be quite complex.
It has a vast number of function calls. You need to worry about ordering, using semaphores and fences to make sure things happen correctly. You need to understand the underlying hardware model. You need to compile shaders offline into a separate IR binary, which you then load at runtime. And so on...
I mean, just check out the official "hello triangle" example[1]. And here[2] for a version which doesn't rely on additional helper functions.
The point made, which I agree with, is that the API itself might be easy. What makes it hard is understanding the domain, the documentation, the tools and other bits around it.
For the case of OAuth 2.0, I do really think it is an easy API to use as such.
What makes OAuth 2.0 hard is exactly the other stuff mentioned above, which is compounded significantly if one uses OIDC on top of OAuth 2.0.
Once you get an understanding for the domain and the technical language used, it ends up being just a few calls with some fairly straight forward data passed. As mentioned in another comment here, it can be as simple as just a single, simple POST call with a username and password to get a token, which you then pass in the usual HTTP header. How is that not easy?!
This is very much unlike certain other APIs. I mentioned Vulkan in another comment as such an example, but there are many others. For example, using Vulkan you must actively take care to add fences and use semaphores to ensure ordered operations. That's on a whole other level of complexity compared to OAuth 2.0.
> What makes it hard is understanding the domain, the documentation, the tools and other bits around it.
But the point is that, if you can't use the API without understanding the domain, then the API isn't easy to use. Saying that knowledge isn't _specifically_ the API (just required to use it) isn't reasonable.
It would be one thing to say "this specific implementation of OAuth2 isn't hard to use" because, for a specific implementation, you'd only compare it against "the knowledge you need that's different from other implementations". But to use OAuth2 in general, you need all the "other" knowledge. Which translates to "OAuth2 is a hard/complicated API to use".
I get your point, and overall I agree that for someone not well versed in authentication and authorization, OAuth 2.0 certainly can be hard to get figured out. It definitely took me some time to grok.
However I still think it's a distinction that's worth making, because documentation, tooling etc is something one can do something about relatively easy.
Not all the things. The specific things mentioned. Actually using the OAuth 2.0 endpoints is easy.
Some APIs can be hard to use, particularly if the problem domain just is hard, like multi-threading. So I don't fully agree with the author in that blanket statement.
> I had to implement my own OAuth 2.0 library, and once I had grokked all the things the author mentions, actually using the OAuth 2.0 endpoints wasn't hard at all.
Usually the point of an api is to abstract away the nitty gritty details, so you can do something more complex with a few simple calls and particial understanding of the problem domain. Seems like oauth fails at that.
For example, nobody expects you to understand filesystem implementations to just open and read a file.
> you can do something more complex with a few simple calls and particial understanding of the problem domain.
Everything is a trade off.
You can find plenty of APIs which work this way. They tend to be expensive in one way or another and so they are often limited in use by cost or by time. If that expense is justifiable, perhaps something you don't call often, and which can be idempotent enough to not have to worry about error states that much, then you are lucky and will be happy with the result.
> Seems like oauth fails at that.
It's in the name. _auth_. Now you have a new trade off. Now between the triangle of secure, cheap, and easy to use we made the most obvious sacrifice of easy to use.
> nobody expects you to understand filesystem implementations to just open and read a file.
How long of a pathname can you have? Are there any OS special characters you can't use? How many directories deep can you go? Is that actually a file and can EAGAIN be generated? Are interrupts enabled? Did you actually open a directory? What _should_ happen when you try to just read a directory as a file?
I was looking at monetizing an API about a decade ago and was pretty shocked to see every API management tool out there had zillions of nice to have features but none of them had a facility to attach a payment gateway — the single feature I needed to have a business.
How is monetising an API different from any other online business? Surely you still just need a place where people create an account, get their API key, and setup payment details.
I dunno it doesn’t sound like a problem that like, needs a solution. I made an app that is basically an API and I just stuck stripe on it and bill people per second used up to a quota.
To me at least there are some nuances, i have worked with bad APIs and had difficulty both trying to see what the provider was trying to achieve and utilise it how I wanted but I don't think I would put that down as being able to work with APIs as hard .
"Hard" and "easy" are words that carry relative meaning. The exact same thing can be correctly described as "hard" or as "easy" if you are comparing against different baselines.
If anybody else is wondering what the heck the blog post is talking about: this is about web dev, which at some point hijacked the term API to mean "custom message protocol".
I read the whole piece and could not figure out what that guy was talking about. He could have replaced API with some other acronym and it would have sounded mostly the same.
> According to Gartner's 2023 hype cycle for APIs, API security testing was at the top. Sitting at the so-called "peak of inflated expectations," API security companies will most surely enjoy two to five years until the industry matures.
Ok.
> Today, though, API security testing is navigating Gartner's infamous "trough of disillusionment" showing that it's trying to become mature.
Lost me.
So in 2003 it was projected they would be around for 2-5 years, but now (2024) they’re in Gartner trough of disillusionment… showing that they’re becoming mature. (?)
> There's clearly money to be made in the API security area … In other words, what these companies sell is a painkiller that doesn't fix the security problem but, instead, provides a way to discover and mitigate it.
???
It feels like this is the example of “bad, making things complicated deliberately”, ok, sure, but what does this have to do with the trough of disillusionment and becoming mature? How are those two things relevant or related? Why is it significant that the 2023 / 2024 out looks are so different? How is this “companies making money” related to the trough of disillusionment?
I feel like if I just skim the article without trying to actually understand anything it’s saying I get a general sense of what they’re saying but damn I’m struggling with it when I read it closely.
Now let me go remind myself how OAuth works again...