6 ms·

> 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 secur

> 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/Authen/OAuth2/Overview.pod#The-Purpose-of-LWP::Authen::OAuth2 https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...

magicalhippo 2y ago
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.
- arka2147483647 2y ago
  > 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.
  - akira2501 2y ago
    > 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?
- theteapot 2y ago
  > ... and once I had grokked all the things ... wasn't hard at all. Can say that about most things.
  - magicalhippo 2y ago
    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.
- davedx 2y ago
  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.
- knallfrosch 2y ago
  Straight forward is opening this: http://user:password@domain.com/ 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.
  - magicalhippo 2y ago
    > 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. [1]: https://www.rfc-editor.org/rfc/rfc6749#section-4.4 https://www.rfc-editor.org/rfc/rfc6749#section-4.4 [2]: https://openid.net/developers/how-connect-works/ https://openid.net/developers/how-connect-works/
    - zo1 2y ago
      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.
      - magicalhippo 2y ago
- RHSeeger 2y ago
  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.
  - magicalhippo 2y ago
    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.
    - RHSeeger 2y ago
      > 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".

magicalhippo 2y ago

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.

arka2147483647 2y ago
> 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.
- akira2501 2y ago
  > 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?
theteapot 2y ago
> ... and once I had grokked all the things ... wasn't hard at all. Can say that about most things.
- magicalhippo 2y ago
  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.
davedx 2y ago
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.
knallfrosch 2y ago
Straight forward is opening this: http://user:password@domain.com/ 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.
- magicalhippo 2y ago
  > 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. [1]: https://www.rfc-editor.org/rfc/rfc6749#section-4.4 https://www.rfc-editor.org/rfc/rfc6749#section-4.4 [2]: https://openid.net/developers/how-connect-works/ https://openid.net/developers/how-connect-works/
  - zo1 2y ago
    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.
    - magicalhippo 2y ago
RHSeeger 2y ago
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.
- magicalhippo 2y ago
  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.
  - RHSeeger 2y ago
    > 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".