API Complexity Is a Lie
apichangelog.substack.com
apichangelog.substack.com
Now let me go remind myself how OAuth works again...
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...
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.
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.
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?
Can say that about most things.
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.
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.
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.
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.
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...
> 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.
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.
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".
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.
"Yeah, we'll get right on that," says the cartel.
then you reminded me about payment processors ...
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?
"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.
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.
:/