1

Currently, we have the issue where we have two codebases (API & Website) calling the same database (along with some duplicate business logic) and we want to streamline this so all requests are routed via our API. We have a public REST API, and we have a website. Some functionality of the website is achievable through the public API, but some will need to come from a private API that only our secure backend can access.

Our website will be re-created as an embedded web app that can be put anywhere and calls our public API's (think a lightweight react/vue project). However, for the official web app running under our domain we will need extra special privileges, such as doing specific admin-related tasks that only we should be able to do (thus requiring a private API). This has led me to create the architecture below:

enter image description here

This architecture achieves the following:

  • Single source of truth (our API) that talks to the database.
  • Only the Web App under our domain has any concept of the private API, and even if the code was inspected requests would be opaque as they are just be routed to a secure backend.
  • Allows us to roll out future first-party projects that can use the same secure backend.

Is this a good approach? Are there some big pitfalls I'm missing? Also I plan on making the Official Web App & the Secure Backend two separate code bases as ideally we would like to swap out the official web app (frontend) with some other arbitrary first-class project and expect it to operate in a similar fashion. It should also be noted the private API will be part of the same codebase as the public API, just with private endpoints exposed so it can access a lot of the business rules it needs to.

Thanks. (Also please excuse my incorrect use of GCP icons).

  • So you are providing two public API's? Or is one only available on the internal network and the other on an external network? – Kain0_0 Aug 7 at 7:31
  • The latter, there is one public API that anyone can use - but for our "official web app" that runs on our domain that will make requests to the secure backend (which I suppose you could class as a 2nd API) - but this will be a blackbox if anyone were to look at the requests (and are only possible from our secure domain). – XanT Aug 7 at 8:06
  • 1
    My quibble is with the "Official Web App" it makes it sound as if this app is being used from outside your local network/vpn. If it is being used from an insecure network then even though this is your "secured" api, it is still part and parcel of your "public" api regardless of whether it part of your "published" api. That aside, are there any shared functionality/service guarantees between the "official" and "public" apis? If there are then the sacrifice of this design is duplication, for independence of control. Otherwise the design itself is feasible, and tenable. – Kain0_0 Aug 7 at 10:24
  • Thanks for your feedback. For clarification, the "Official Web App" is a public website that can be used by anyone, however it is hosted on our network and communicates to our secure backend due to us needing to make requests other 3rd-party hosted web apps cannot do. The official website, using the private API will have some similar functionality to the public API, so there is an issue of some code duplication there. Do you have a suggestion for dealing with that? Appreciate the feedback. – XanT Aug 7 at 13:39
1

A Game of Questions

Gotta love Architecture, it is fractal.

From what I can piece together your "Official" Web App is actually two pieces.

  1. A Web Page (which executes within the user's browser)
  2. A Public API (which your web-app uses to do stuff)

Additionally you have a Published Public API used by the wild west which isn't used by your Web App.

And at least some of the functionality is similar enough between the two that it might be reasonable to reuse it.

Private API
     |
     V
Secure Server-----------------------> Published API
     |                                       |
     V                                       V
Server Side Web APP API                Third Parties
     |
     V
Client Side Web App

A pretty diagram, a mess of an implementation.


First I would cut out the nonsense about your "official" web app.

Any code that is run on not your computer is code not under your control, it is no more trustable than those third-party web apps. Particularly given that any suitably motivated party doesn't even need your official web app in order to dispatch http requests to your server. Even a stream based http/2 communication is not immune (though it does require more sophistication).

Now you could claim that a webserver generating static/dynamic web-pages from a local API isn't exposing an API. Except it is, the API is just more obtuse as the API is the web page itself. Send the right request, and get the response back in html as opposed to json/xml. Security through Obscurity isn't secure.

What this boils down to is that both the Public and Official API's are both Public. The difference is whether or not you Publish it with associated usage information.

That changes the diagram again.

Private API
     |
     V
Secure Server-------------------+
     |                          |
     V                          V 
Web App/Page Server        Public API
     |    ^                     ^
     |    |                     |
     |    +---------------------+-------+
     V    V                             V
Client Side Web App             Third Party Clients

But this is conflating concerns. The secure server is where the API/WebServer live, while everything else is about the service. Either we need to drop that out of this perspective, or actually include the other important physical locations.

Dropping it out

 Private API
     |
     V
 Public API-----------------------+----------------------------+
     |                            |                            |
     V                            V                            V
Web App/Page Server------>Client Side Web App          Third Party Clients

Adding it in

===Backend Servers================|==========Licensed Services=======
                                  |
                                  |
        Internal API's            |       Third-Party Serivce API's
             ^                    |                   ^
             |                    |                   |
=============|===========Secure Bastion Server========|=============
             |             *Probably in DMZ           |
             |                                        |
             +---------------------------------+      |
                                               |      |
                                               V      V
        Web App/Page Server                   Public API
             |       ^                            ^
             |       |                            |
             |       +----------------------------+
             |       |                            |
=============|=======|=======Client Machine=======|==================
             |       |                            |
             V       V                            V
         Client Side Web App              Third Party Clients

This would suggest having a single set of of encompassing API's. Even if that api is subdivided into separate micro-services, or a single monolithic service. Both can be made to work.

It also suggests that basing access on client would be foolish. However an account based authentication mechanism would give your users the power of choice. The ability to use your own web-app, or the ability to use a third-parties. That account provides them with access to ascribed services at their ascribed levels of service (should the client support it).

If you still wish to provide client specific functionality, consider a client certificate which is used to authenticate the client app itself and unlock client app specific functionality. This could be used to monetise those third-party offerings, should they desire some of the features available to the official app, they can pay for those to be enabled to them (regardless of the specific user).

You could even go further and extract your own web-app from the secure server, and distribute it through third-party channels. eg: geo-caching services.

| improve this answer | |
  • This is an incredibly detailed and insightful answer (and thanks for the diagrams). Just for clarity we are keeping our monolith for the API and not breaking it up into lots of micro services (at least for the meantime). But from what I understand you are suggesting that everything routes via the public API, and the depending on the origin of the public API request(and if its coming from trusted/not trusted architecture) we then make the decisions of what functionality it has access to? – XanT Aug 12 at 2:17
  • Not quite, I'm suggesting that the question isn't "trusted" software, but a verifiable identity. Prove that the user/organisation using/making the software is who they say they are, and ascribe extra-permissions above stock public access based on that proof. If they can only provide feeble proof, then some permissions are not available, if they can provide gold standard proof (such as two-factor) then they get gold-standard access. Proof deteriorates with age, so a two-factor yesterday is not as shiny as one done today. – Kain0_0 Aug 12 at 3:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.