The setup is the following:
Public API
- Entry point for users of a public website.
- Endpoints are all public and reachable without credentials
- Handles easy request (country completion etc.) itself, all other requests are forward to the Business API
Business API:
- Has access to the business logic of the application
- Has authentication/authorization on every endpoint
- Dedicated credentials for Public API (Basic Auth)
The use case:
The application gives a login user access to certain resources in the frontend. For this to happen the frontend requests an access token from the Public API. The Public API can not handle this request (no access to business data or users) and forwards it to the Business API. The access token gets created and passed back through the Public API to the frontend.
After receiving the access token, the frontend makes another request to the Public API with the Authorization
header set to Bearer [access token]
.
The Public API gets the request, can not handle it and proceeds forwarding it.
During forwarding the request it sets the Authorization
-Header to inject the credentials for the protected Business API endpoint. Now the access token is lost. Therefore the Business API determines, that whoever is making the request is not authorized to access the requested resource.
My question now is: What is the best (read: most standards oriented) way to handle this setup.
My thoughts:
First of all, please feel free to tell me, that all of them are absolute garbage, if they are :D
I could just not add the additional protection to the specific Business API endpoints that deal with access token requests. Theoretically they are protected by the access tokens, but this could be a policy problem, because there are no public (read: unprotected endpoints) in the Business API.
I could MOVE the existing credentials into another header, for example
X-Authorization
. The pro is obvious: it would just work. But IF I were to do this, I would only do it according to an existing standard. Libraries that work with authentication/authorizations are mostly not flexible with the headers they are looking into for that kind of information. And why would they? It is an established standard. If there was a good standard, I would probably be able to add the functionality to any open source library pointing to the standard in question.
Proxy-Authentication
does not seem to be the correct answer here, since it seems to be used to auth vs. the proxy and no the resource behind it. Since the proxy in question here is the Public API which is public and open, I would not want to misuse them. Also I would like to avoid exposing to the users that they are talking to a proxy.