I have a front end (WEB GUI) app that I designed (Python for now + JavaScript in the future) that I use to access a controller, it uses REST APIs.

I want to publish this app in the cloud so that others could use it.

The biggest issue I am seeing is the security side as the app needs to authenticate with the remote server (a controller itself) and start sending tasks to the controller that will translate that in internal REST APIs to control for processes on downstream servers

Is there an authentication flow that will guarantee the owners of the controllers that I (the publisher of the front end) do not intercept the authentication flow and I gain unwanted access to their servers ?

My idea is to use a two steps authentication/authorization process like below. Is there a better way? Please edit this diagram if you have suggestions
enter image description here

After looking closer at the issue I think this is a better architecture

enter image description here


The general architecture you pose makes sense. I think if I were going to do it, the main tweak I would make would be to completely hide the interactions with the on-prem controller behind an API backplane. So, something, perhaps, like this:

       [GUI]   -----------> |     |      .-> (Audit Database)
                            |     |     /
       [Webapp] ----------> | API | ----
                            |     |     \.-> { Message Queue } ----> [On-Prem Controller] ---> { Managed Resources }
       [Mobile] ----------> |     |
                    [OAuth / OIDC Provider]

By removing the desktop app's ability to talk directly to the controller, you plug a potential security hole by allowing everything to remain cleanly separated. Also by wrapping everything in an API you can apply consistent security rules to who is allowed which operations and you can maintain an audit of what was sent by whom and when. It also allows you to plug in additional interfaces later, should the requirement ever come up.

Another advantage is that the message queue could be either push or pull. The advantage to having the on-prem controller poll for commands is that it allows you to have a firewall in between them without forcing the client data center to open any ports.

As you've mentioned in your post, being very strict on security is imperative to minimize the risk to which you are exposing your potential customers, so think that model through thoroughly.

Good luck!

| improve this answer | |
  • The issue here is that the GUI app that sits in the cloud is not trusted, only the user using it. The potential client/user might suspect that the cloud GUI could be used for a Man in the middle attack. Not sure how your suggestions add that. The GUI does use APIs to talk to the o prem controller – MiniMe Jun 29 at 19:02
  • Also see my update – MiniMe Jun 29 at 19:17
  • That's fair. UIs (however built) should always be treated as non-trusted. The big difference is that, as sketched, the untrusted UI must be able to directly communicate with the controller, which means that it must be able to reach it (i.e. there must be a hole in the firewall). The API layer can either make decisions based on the oauth token or pass it along for something else downstream to act upon. Either way, it is the user's access that grants permission (assuming resource owner flow) not the app's. – Michael Jun 29 at 22:17
  • "it is the user's access that grants permission (assuming resource owner flow) not the app's." The issue here is that if the access is done via the GUI this can be leveraged for a man in the middle attack. – MiniMe Jun 29 at 22:23
  • I'm not sure I follow. The GUI should be untrusted either way (raw user input and all that), which is why the brains need to be consolidated somewhere else. – Michael Jul 1 at 13:29

Is there an authentication flow that will guarantee the owners of the controllers that I (the publisher of the front end) do not intercept the authentication flow and I gain unwanted access to their servers ?

Yes, that is exactly what OAuth is designed for. If you use the Authorization Code Grant flow of OAuth, then the user's credentials are only communicated with the OAuth authorization server and your app only gets an access token that can be used (for a limited time) to access the OnPremController (the Resource Server in OAuth terms).

The steps in this flow are:

  1. User triggers a login in your WEB GUI (e.g. press Login button)
  2. WEB GUI responds with a HTTP Redirect to send the user to the Authorization server for the actual login procedure
  3. After successful login, the Authorization server issues a HTTP Redirect response back to the WEB GUI with an "authorization grant"
  4. The WEB GUI uses the "authorization grant" to request an access token from the Authorization server
  5. The WEB GUI uses the access token to make requests to the OnPremController.

As the actual login communication between the User and Authorization server completely bypasses the WEB GUI, there is no way the login credentials can get in your hands.

| improve this answer | |
  • True but in the initial design (first diagram) the token goes back to the GUI. The SaaS provider (the GUI owner) could get a copy of the token and do what he wishes with that token, and that is exactly the problem I am trying to solve. So far the only option I am seeing is the diagram two but that takes the GUI offline. The communication could be simpler and more streamlined if the GUI sits like in the first diagram. I would love to find a solution that allows me this and still prevents the token interception mentioned above – MiniMe Jun 30 at 14:49
  • @MiniMe, if you can't trust the WEB GUI with a token with limited lifetime, how do you envision the WEB GUI making requests that require authorization, where that token is the proof you are authorized? – Bart van Ingen Schenau Jul 1 at 5:46
  • For the moment I can't hence my question. I am hopping that others who know more about authentication flows will suggest a solution. – MiniMe Jul 1 at 11:35

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.