X.509 certificates issued by your private PKI would do the trick.
You'd have to implement a registration / enrollment process during which you'd handle the setup but that'd be a one-time thing (plus a "renewal" process every few years or so).
Although it isn't necessarily the most "user-friendly", pretty much every HTTP(S) client and server in existence supports using certificates to authenticate clients.
As a security nerd, this is what I think I'd prefer, however...
--
An alternative that's probably more popular and "user-friendly" -- and more likely to be recommended (especially here on HN) -- would be to allow users to generate and manage API keys tied to their accounts.
You could then either 1) require everyone to authenticate to the back-end services using their API keys (even "free" users) or 2) make authentication optional but implement strict rate-limiting and/or quotas for unauthenticated requests.
--
EDIT: There are two other similar / closely related methods that I forgot to mention which are quite easy to deal with (both client-side and server-side) and supported practically everywhere (as, if memory serves, they've been around since HTTP 1.0 and 1.1, respectively!): HTTP Basic Authentication and HTTP Digest Authentication. The latter is basically the former with MD5 hashing added, although neither are particularly "secure" nowadays compared to the alternatives. This is much less of a concern if all requests and responses are being carried over a TLS-encrypted session, however.
> Although it isn't necessarily the most "user-friendly", pretty much every HTTP(S) client and server in existence supports using certificates to authenticate clients.
It's also not limited to HTTPS. Other protocols like SMTP and IMAP can use these as well.
One good way to get 2FA is to not only verify the client TLS certificate server side, but also require the user to send their username and password when logging in. Server side, the verified certificate could be checked against the credentials provided to see if they match.
You'd have to implement a registration / enrollment process during which you'd handle the setup but that'd be a one-time thing (plus a "renewal" process every few years or so).
Although it isn't necessarily the most "user-friendly", pretty much every HTTP(S) client and server in existence supports using certificates to authenticate clients.
As a security nerd, this is what I think I'd prefer, however...
--
An alternative that's probably more popular and "user-friendly" -- and more likely to be recommended (especially here on HN) -- would be to allow users to generate and manage API keys tied to their accounts.
You could then either 1) require everyone to authenticate to the back-end services using their API keys (even "free" users) or 2) make authentication optional but implement strict rate-limiting and/or quotas for unauthenticated requests.
--
EDIT: There are two other similar / closely related methods that I forgot to mention which are quite easy to deal with (both client-side and server-side) and supported practically everywhere (as, if memory serves, they've been around since HTTP 1.0 and 1.1, respectively!): HTTP Basic Authentication and HTTP Digest Authentication. The latter is basically the former with MD5 hashing added, although neither are particularly "secure" nowadays compared to the alternatives. This is much less of a concern if all requests and responses are being carried over a TLS-encrypted session, however.