0
votes

We have a single API X which needs to be available both internally and externally to the company. Is it possible to allow basic authentication to X using only a Client Id for internal consumers but require oAuth authentication to X using a Client Id and Auth Token for external consumers? Preferrably, with client id and oAuth fields all passed in the http header to both APIs?

We currently have a single product containing two APIs (API X and an oAuth 2.0 provider API scoped to API X). We have added two security definitions to API X, Option 1 is oAuth and Client Id. Option 2 is Basic (Client Id only). For oAuth, we are using a confidential, application flow scheme where app sends client id and secret to oAuth provider API, and gets back an auth token and then passes the (same) client id and auth token to API X.

OAuth access to API X is working fine using http headers, but Basic access to API X only works if we pass client id in the Query string. We'd prefer to always only use http headers.

1
This is probably not helpful for you as this is an apiconnect specific question, but more generally it's definitely possible for an API to require either a Bearer or Basic authorization header. - Evert
Thanks Evert, yes I would think generally speaking it should be. - C. Suttle

1 Answers

0
votes

I'm still very open to a better answer but We have found a workaround.

We removed the Basic authentication security definition from API X so that it only has the oAuth 2.0 security definition. We then created a new API Y which is identical to API X except that it only has the Basic authentication security definition. It has the same base path and paths as API X. We created a second Product and added API Y to it. Just to recap, Product 1 contains API X and its oAuth API. We subscribed the internal consumers to Product 2 and external to Product 1 and we have success. Authorization is completely handled within the headers.

Surely there is a better way?