Surely there are multiple layers.
First, transport layer security.
Use TLS in every network link.
Then, application level security.
Between Drupal and Edge
If Drupal is sending API requests to Apigee Edge, then the trust and authentication must be enforced by Edge. The drupal server should have a clientid + secret (if using OAuth2) or an apikey (if using generic tokens). This secret must be stored securely on the drupal server and then sent with every request. When using oauth, your drupal app will exchange the clientid+secret for an oauth token. Regardless whether you use a token or API key, from that point onward, the mechanism is very similar: drupal sends the apikey or token to Edge with every API request. Edge verifies it with OAuthV2/VerifyAccessToken or VerifyApiKey. And then honors the request only if the verification succeeds.
Between Edge and Oracle
You need to store secrets in Edge in order to be able to authenticate to Oracle. The Apigee Edge Vault is good for that. Retrieving secrets must be done through nodejs (Currently). So you need a nodejs endpoint, which retrieves the secrets, authenticates, and perhaps stashes a token or session in cache. Or, the nodejs targetendpoint could simply continue and connect to Oracle.
Message-Level security
You may wish to add in checksums, HMACs or other message integrity guarantees. This is usually done by only the most security paranoid people. In fact I was explaining this to a person not long ago, and they exclaimed: "WHY?!!? I Can rely on TLS!" That's completely true, except when it's not. Message-level security between Drupal and Edge can mitigate the exposure associated to a TLS vulnerability.
When I say "message level" - what I mean is, the client would sign or perform an HMAC on the payload , and embed that signature or HMAC into a header, when sending the payload. Then, on the Edge side, you'd need to do the verification of said signature or HMAC. HttpSignature is one way to do this. There are others. (OAuthv1.0a, for example)
LinkedIn
Twitter
