Ask HN: Which method of authentication for a B2B HTTP API?

I would use JWT restricted to a specific algorithm.. or..<p>Use something like GCP service-accounts. So require that the client provides a service account ID that they control, and that the requests are authenticated with an id_token from the given service account, and audience set to your service.<p>That way you won&#x27;t need to exchange secrets or keys, and consumer can delegate permissions within their organization.<p>I&#x27;m pretty sure AWS IAM has similar mechanisms for delegating access.<p>If based outside the cloud it doesn&#x27;t add much for your customer, but if you customer is in the cloud they won&#x27;t have to manage secrets.<p>Downside is vendor lock-in, of course, but supporting multiple cloud vendors wouldn&#x27;t be hard.<p>Maybe not the most idealistic solution, but very pragmatic -- especially if your customer is in a cloud already.<p>disclaimer: I work for Google (not GCP), these are my personal views.

Not a security guy in any sense, but working with b2b often.<p>Request signing by a shared secret (jws or jws based) is what I see at almost everyone we work with in small business range. But I doubt its purpose really, they do not rotate keys ever, and also if someone intercepted a request in a plain text, they could still do some damage. For persistent links rotated shared secret simply attached to a request, iow basic auth, would be enough.<p>I think some of them would do that, but looking “unprofessional” in eyes of your partners feels bad. They are happy to log into their email and banks with a cookie, but in b2b it’s a bad form. Consider this if politics is a thing.<p>You probably want to analyze your attack surfaces and use a corresponding technology. If it’s just info&#x2F;events, basic auth is okay. If the access is subject to change&#x2F;revoke, use time-limited tokens like jwt. If it’s financial ops, sign every request so that an attacker couldn’t forge a request in their favor. Tldr it depends.<p><i>Basic auth would work well for our needs and it&#x27;s very easy to build and use</i><p>So much yes. For some companies it takes weeks to implement correct auth, because developers cannot write good guides on average and don’t understand each other contrary to common beliefs. They aren’t all FAANG graduates. Integration slows down so much because of that. Make sure that you provide enough documentation, <i>working</i> examples and in-API auth debug modes, if you decide to implement non-basic auth.