4 ms·

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

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
    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/samples/api/hello_triangle/hello_triangle.cpp https://github.com/KhronosGroup/Vulkan-Samples/blob/main/sam... [2]: https://github.com/SaschaWillems/Vulkan/blob/master/examples/triangle/triangle.cpp https://github.com/SaschaWillems/Vulkan/blob/master/examples...

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
  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/samples/api/hello_triangle/hello_triangle.cpp https://github.com/KhronosGroup/Vulkan-Samples/blob/main/sam... [2]: https://github.com/SaschaWillems/Vulkan/blob/master/examples/triangle/triangle.cpp https://github.com/SaschaWillems/Vulkan/blob/master/examples...