I would like to propose you implement a way for a flow to be initiated with an auth token. Using OAuth 2.0 on-behalf-of flow, this token could then be used to run other actions in the flow in the context of the token. A flow could be created by one user and run as another user.
Following the way OBO works, the client ID of the token passed in during flow initiation would be pre-configured to work with client IDs of select flow actions. Flow connectors this would be awesome for include:
1. Outlook connector
2. SharePoint connector
3. Planner connector
4. <Insert Office 365 service> connector
It would be on me to make sure the token I pass in has a correctly configured Application with a knownClientApplications value in its manifest. You would then use the clientId and secret you have already for all AAD based connectors to retrieve a token based on the token I send when initiating the flow. From there, you run the flow action as you already do; passing in the token retrieved via OBO flow as opposed to the connection normally used today (which I’m assuming is a token as well but tied directly to the clientId/secret of the connector in question).
This could be controlled in a couple ways to make it manageable...
1. A flow could be flagged as requiring authentication. It will not run if a token is not passed in during initiation. Could also be flagged as optional to support running the flow as it runs today *or* with a token passed in.
2. A place where I as an admin could configure a client Id as ‘connected’ to other connectors in my tenant. I could specify that the JWT tokens coming in need to resolve to this clientId and flow will only attempt to use the OBO flow on the connectors selected here.
a. Maybe I only want to allow users to make SharePoint updates using OBO so Flow works more like SharePoint Workflow, but I don’t want to allow use of Outlook or Planner connectors. I can’t think of a reason why you would want to limit this.
You would then need to publish the clientIds of Flow Connectors that would support this. I assume those would all be in-house and you could probably have a way to support custom connectors as well. If I’m controlling the clientId and secret of both the initiating trigger and an action in the flow, I could easily get this set up once it’s in place for me to use.
Thank you for the suggestion. Today, we already support running in user context when there is a user present. For example, if I select a file in SharePoint and start a workflow on that file, that workflow can run in either my context, or the context set up by the author of the flow (as decided by the author). This is possible because we have the user's AAD identity and token when the user is invoking the flow.
However, for automated flows that run in the background, we no longer have any securable identity from the end user who happens to cause that event. As a result, we have no way to run on behalf of that user. That being said, we understand that this is important scenario and one we will see if there's some other way to solve.