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.