Password Protection

[stratford]

Hi,

What's the best practice of storing Password variables in flow? Is there a special way to treate sensive variable values?

Or we just create a service account, save the password in clear text in flow variables.

Thanks

[MarkStokes]

This is an interesting question. My views may need some verification and confirmation.

1. Your Flows are generally protected to be viewed / edited by the Flow Owners. I’ve not checked but I’m not sure non-owners will get to edit the Flows, read the Flow definition or access the Flow run log. So, on the face of it... safe (ish). This needs to be verified whether I am right here (I’m on my phone in bed atm!)

2. What do you need a password for / to access? Flow is designed to use OAuth to authenticate against external systems so that passwords don’t need to be stored / used. My first suggestion would be to try and build a custom connector that allows you to abstract the username and password out do the Flow definition.

3. If the external system won’t allow 2. To be possible then you could store the password securely in something like an Azure Key Vault (or some other secured area) and use an action with a service account OAuth connection to get the password at run time. This may still expose the password in clear text in the Flow run log.

4. When you “use” the password (such as in a HTTP Request as I can’t think where else you’d use it) make sure you are doing it over a SSL protected connection otherwise Flow is the least of your worries.

5. Don’t store clear text passwords in Flow.

-Mark

[stratford]

Thanks. My scenario is we are doing integration with Dynamic 365 using flow. The out of box Dynamic Connector for creating item doesn’t support passing connection details as variables. I am planning to call REST API through HTTP connector with the access token.

We have registered Dynamics in Azure AD. However, the HTTP Request to get the tokens needs the password and username in the request body. So I was wondering what’s the best way of handling password? The password currently is only owned and maintained by our office 365 administrator but the Flow will be accessed by developers.

[MarkStokes · Accepted solution]

I see.

So, the only reason to store a username and password is so that you can get the access token?

In that case, do that bit some place else. In your Flow, just have an Action that gets the current Access Token at the start then you can use that throughout.

Store the Access Token in an Azure Keyvault (preferably, or SharePoint List, or somewhere else) and then have another process that gets a new access token when the current one if due to expire. You should be able to get the expiration date / time of the token when you receive it so can plan when to renew it in good time.

The token refresh action can be manual (probably not preferred) or some other method. I am trying to think of how I would do it. I'd probably write it into an Azure Function that gets the username and password out of a Keyvault and updates it somewhere.

[MarkStokes]

Or you could register an App in Azure AD that has permission to D365 and use the ClientID and Secret instead of the Username and password and then lock down the permissions that App registration has.

[mdevaney]

@stratford @MarkStokes 
The post marked as a solution is outdated.  As of 2021, we can safely hide a password by:

• Secure Inputs + Outputs of any flow actions using the password
• Retrieve keys from a (free) Azure Key Vault using a flow action so you don't need to store passwords inside a flow

Check out this article if you require full instructions:

Link to Article - Hide Passwords In Power Automate Flows (and API Keys, Secrets)

https://matthewdevaney.com/hide-passwords-in-power-automate-flows-and-api-keys-secrets/