I am building an application (“A”) that can interface with a 3rd Party data API (“B”). A is commissioned by Organization “X”, which has data on B. Users of A need access to Org X’s data on B. However, B has no record of A’s users.

enter image description here

A and B live on different servers and communicate through public internet. User’s of A login with username and password and are issued an expiring access-token that authenticates HTTPs requests to A’s data API. My question is how to best secure communications from A’s data API to B’s data API.

In other words, what is the best way to ensure request’s to B are really coming from A? Should A store some kind of non-expiring Bearer-token that B can authenticate?

Note that the developers of B have agreed to make some modifications to B in an effort provide A the data it needs, but modifications should aim to be minor.

  • 1
    Protocols like JSON Web Tokens support message authentication (JSON Web Signatures) which could serve this purpose, so it may depend on what message format you've inherited for the A<->B communications.
    – gowenfawr
    Commented Apr 21, 2017 at 16:08
  • Are these backend calls, or are these routed through the users' browser?
    – ndrix
    Commented Apr 21, 2017 at 16:13
  • Based on the diagram you shown, it sounds like the Users will never interact with B directly. Does B need to keep track of individual users who are hitting A? If not, it sounds like the authentication between A and B can be done via an API key, a single username/password combination, or some other common authentication mechanism. Commented Apr 21, 2017 at 17:31
  • @ndrix - These are backend calls, though they might be initiated by a browser interaction. User clicks a button, browser sends request to API A, API A understands it needs data from API B to complete the user's request. BTW, I'm the author of the question but posted the question as a guest by accident.
    – Rich
    Commented Apr 21, 2017 at 19:18
  • @user52472 - "B" will not keep track of users hitting A. It does keep track of the organization/group that those users belong to. I like the ID of an API key. Curious if you have suggestions on where/how to store that API Key. Could be part of the API A's configuration file or encrypted in API A's database? BTW, I'm the author of the question, but posted it as a guest by accident.
    – Rich
    Commented Apr 21, 2017 at 19:23

1 Answer 1


Since these are backend calls, there are a few options you can do:

  • Certificates : SSL/TLS allows mutual authentication whereby you have both end to end encryption and authentication at once. If you enable client certificates on API A (and check it on B), and vice versa - you have a strong tunnel. Furthermore, you can use certificate pinning - in which case it may be okay to use self signed certificates. As long as Api B can verify that A's private key was used to sign the traffic sent, you have this trust.

  • Shared secret : You can encrypt the traffic with a shared secret between both parties (A and B), this would of course require that you have strong secrets and a healthy key rotation policy. The shared secret will act as authentication (ie: if you know the secret, you're the right party). This could be seen as an API key or anything that's known to both parties, but no one else.

  • Token based : You can get bearer tokens from a general Identity provider (IdP); which Api A will get with a appID / Secret combination. The (trusted) IdP will create a signed token which APi B can validate and henceforth, trust that the request came from 'A', as verified by a trusted 3rd party, namely the IdP.

Needless to say, Api B should be accessible over an HTTPS connection, and as defense in dept you could ACL network devices in between.

  • As far as ease of implementation (read least amount of rework to application B), I would recommend the Certificates option. Assuming you're connecting to to B via a web service, you should be able to set up dual certificate validation in whatever application is hosting B (Apache, IIS, nginx, etc.) Commented Apr 21, 2017 at 21:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .