cancel
Showing results for 
Search instead for 
Did you mean: 

Support AAD On Behalf Of authentication to run flows in the context of the user

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.

Status: Under Review

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.

Comments
Level 10

When creating a Flow on a SharePoint list or library, it would be great if that flow ran in the context of the user initiating it rather than the author of the Flow.

 

For example, we have many scenarios where a process needs to execute when an item is created in a list. Currently, when I author a Flow to do this, the process executes with my permissions, so items created or edits made in the course of that Flow are attributed to me, not to the person who actually caused the Flow to run. 

 

Ideally, for each action in the Flow, the designer should be able to designate whether that action uses their connection, or a connection that the user/initiator supplies at the time that they run the workflow. So, a "BYO Connection" option, or maybe "Author's Connection"/"Initiator's Connection".

Flow Staff
Status changed to: Under Review

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.

Level: Powered On

This is definetly something to be worked out if nothing more than for a security context. Currently if I build a flow and normally i'm the one who montiors it, but for redundency/required disater recovery processes that flow is shared with a co-worker. I don't want two versions of the same flow as the becomes a which version is the most up to date. But the flow has my user authentication baked into it for what ever connectors I am using. So said co-worker could take a flow that uses my authentication to outlook or sharepoint to gain access to information they wouldn't otherwise have. From my emails, to documents that I am allowed to access but they are not. Or worse yet send email or create documents posing as me. I understand the retaining of stored credentials for automated running, but anytime a flow is edited or run manually it should prompt for authentication and use that token for the one time run (for the run manually option) or save the new/reentered token for future runs (the edited flow scenario)