hckrnws
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...
> What is hard isn't the API ...
Clearly someone who hasn't gazed into the maw of OAuth :Þ
Though I guess the article wouldn't call that an API but "api security" added to the real API. A bit potatoes potatoes from my eyes.
----
Fun reading: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
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.
Straight forward is opening this:
http://user:password@domain.com/
Straight forward is a physical lock with a key.
Doing an OAuth dance that requires 5 steps in the best case is not "straightforward" if that word means anything.
> 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.
[1]: https://github.com/KhronosGroup/Vulkan-Samples/blob/main/sam...
[2]: https://github.com/SaschaWillems/Vulkan/blob/master/examples...
What you've said seems to be able to be re-phrased as
> Using OAuth 2.0 isn't hard. Once you have learned enough to literally re-write the library for it from scratch, you should have no problem using it.
Which, from my point of view, is another way of saying it's really hard to use. If I bought a car and the the owner's manual said
> Once you are able to take the car apart to individual components and re-assemble it, you should understand it well enough to drive it
I'd label it as hard to drive.
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.
> ... and once I had grokked all the things ... wasn't hard at all.
Can say that about most things.
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?
Using OAuth 2.0 [as documented, when the implementation matches the docs] isn’t too bad, but many many companies diverge in weird ways IME.
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.
Mostly in deciding and tracking what to actually bill for.
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.
At least there are licensing gateways nowadays[0]. Now you just need to integrate it with a payment service of choice.
you know i was reading the comments and i was thinking that apis are easy
then you reminded me about payment processors ...
That's a great example of adding features and feeding the complexity instead of offering what customers want.
I want to argue: "Well, capitalism contends that someone will show up to offer that product."
"Yeah, we'll get right on that," says the cartel.
> Anyone telling you that working with APIs is hard isn't telling the truth.
Having encountered a difficult to use API, I must disagree with the thesis.
Or I'm a one of the many people not telling the truth. Who can know for sure?
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 .
Words are squishy.
"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.
I was wondering wtf he was talking about. Why did they do that?!?
Comment was deleted :(
> 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.
:/
Crafted by Rajat
Source Code