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

3 Answers 3


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.

  • 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
    Commented Jun 30, 2020 at 14:49
  • 1
    @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? Commented Jul 1, 2020 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
    Commented Jul 1, 2020 at 11:35

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 and no. It depends on how configurable your permissions are on the identity server.

Identity servers allow for a user to log in to an authoritative source. That signup process happens between the user and the authoritative source, and does not involve your frontend app directly.

However, your frontend app does receive access to the token (generated from that login procedure), which the express intent for your app to use that token to talk to the controllers.

So when you say:

that I (the publisher of the front end) do not intercept the authentication flow and I gain unwanted access to their servers ?

It's a bit ambiguous what you mean.

You do not intercept the login process, i.e. at no point did you handle or even have access to the user's credentials.

But you do in fact have access to the authorization (and thus authentication) token that the login process yields, and are able to use this to send requests to the actual backend. How you use that token is up to you, so you can technically try to fire every possible request to the backend using that token.

The end user has no way to control which requests you do or don't send to the controllers. At best, they can simply revoke the token (from the authoritative source) to invalidate it and make it impossible for your frontend app to continue to act on the user's behalf.

However, a well written identity server will have given you a very restricted token that ensures you can't do anything other than what you have been given permission to do.

Identity providers generally implement scopes for this exact purpose, where a user (or the identity service itself) is able to generate a specific token with a very narrow and specific allowance. This allows the user to know that the frontend app cannot abuse the token for anything else that it did not give permission to.

For example, if I login to MyFancyApp using a Google account, Google will tell me that MyFancyApp is asking for access to my pictures and my calendar. If I only grant permission to access my calendar, not my pictures; then I can rest assured that even if MyFancyApp were to malevolently access my pictures, it wouldn't be able to do so with the (calendar-only) token that I provided it with.

Do note that some frontend apps may outright refuse to do anything unless they receive all (or certain) permissions they ask for. That is the app designer's decision, as some permissions may be essential for the app to work.

Everyone retains their own control:

  • The app can indicate exactly what it intends to do. Good identity servers will never return a token that allows more actions than the app has asked for. The app is also able to refuse to work for a user who has not given the required permissions.
  • The identity server alerts the user of the requested permissions. The user can make an informed decision on whether to give those permissions or not. Whether partial permissions can be given depends on if the identity server has such a feature.
  • The user will at all times remain informed about what the app can do with the provided token.

This all hinges on the identity server being a trusted middle man, of course. We assume that the identity server keeps the user informed, and that it does not sneakily hand out tokens with more access than the user agreed to.

If the identity server keeps the user in the dark and effectively conspires with the app; then all bets are off. The user can only trust your app as much as the user can trust their identity server.

  • There is lots of ifs that I would like to avoid if possible. Is there a way to control how many sessions a token can be used for and to generate a token that will expire when the session is closed ? The controller uses REST APIs I am considering second factor authentication and any new session should get a prompt for that second factor..so having the token for a session won't help because there is active session with that token already and when the session is closed by the legitimate user the token becomes void
    – MiniMe
    Commented Jul 30, 2020 at 18:31
  • @MiniMe: All of these things are things you can build. Your backend will be validating the token with the identity server, so the identity can track how often it's been used. Watch out for "sessions" as people can use multiple browsers or devices and don't expect to get caught up on that. You can certainly build those multi-session blockers, but only do so if there is value to gain from (or protect by) it. Even Spotify allows you to use your account from many devices at the same time, it's only the audio playing that is limited to one device.
    – Flater
    Commented Jul 30, 2020 at 21:06
  • @MiniMe: "so having the token for a session won't help because there is active session with that token already" How do you know that a token is in use and the previous session hasn't been closed? What if I take my cookie, put it on another browser/device, and send requests with that - how are you going to notice that? I'm not trying to start a discussion here, I'm trying to point out that you may be trying to control things that aren't worth the effort of wrangling them.
    – Flater
    Commented Jul 30, 2020 at 21:09
  • when the legit user opens a session the system limits the number of sessions to one so it is impossible for the attacker to reuse the token during this time. When the legit user closes the session the system cab blacklist the token and the attacker can't use the token it eventually captured
    – MiniMe
    Commented Jul 31, 2020 at 13:28
  • @MiniMe: Define "legit". When you use that token for authentication, then anyone using that token is defined as "legit". That's the point of an authentication token. If you want some additional tracing, e.g. on IP address or MAC address or ... then that's all fine, but that's just something you have to build the way you want it. There's no universal answer here - build it exactly how you want it.
    – Flater
    Commented Jul 31, 2020 at 14:57

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!

  • 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
    Commented Jun 29, 2020 at 19:02
  • Also see my update
    – MiniMe
    Commented Jun 29, 2020 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
    Commented Jun 29, 2020 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
    Commented Jun 29, 2020 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
    Commented Jul 1, 2020 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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