[distalx]

On the B2B2C section, my mind immediately went to OAuth. For a developer like Bob giving his end users access to a service, wouldn't a standard OAuth flow where his users grant permission to his app would be the more conventional and secure solution?

It feels like that model handles key management, delegation, and revocation in a well-established way.

What am I missing here that makes this a better fit?

[motorest]

> What am I missing here that makes this a better fit?

From a cursory read, the answer is "it doesn't".

The blogger puts up a strawman argument to complain about secret management and downloading SDKs, but the blogger ends up presenting as a tradeoff the need to manage public and private keys, key generation at the client side, and not to mention services having to ad-hoc secret verification at each request.

This is already a very poor tradeoff, but to this we need to factor in the fact that this is a highly non-standard, ad-hoc auth mechanism.

I recall that OAuth1 had a token generation flow that was similar in the way clients could generate requests on the fly with nonces and client keys. It sucked.

[distalx]

Spot on. The burden and complexity of that cryptographic signing on the client is exactly what OAuth2 was created to avoid. Thanks for making that connection.