Workflow authentication and secrets

A workflow should have only the access it needs. Keep credentials out of logs and survive planned rotation without silent failure.

Map each connection before choosing between an API key, a delegated user token or application access. Decide the authority behind each step rather than inheriting it.

Choose an identity for the job

Write down which service the workflow calls, which records it must read or change, and whether a human must be present. Use those requirements to decide which permissions and sign-in model fit.

Other APIs have different models, so check the provider's current scopes and expiry rules. A shared administrator credential is convenient but makes it hard to contain damage or explain who acted.

Use separate identities for development and production where supported. Restrict scopes to the required records and actions, then test a task that should be denied as well as one that should succeed.

If a connector cannot be limited enough, document the risk and consider a different integration route.

For Microsoft tokens, the permission type can also be checked in the token claims when diagnosing an integration: application permissions appear in the roles claim, while delegated permissions appear in the scp claim. This can help confirm whether the workflow received the kind of authority intended, without treating the two permission models as interchangeable.

Store and rotate deliberately

Keep keys in an approved secrets store or platform connection setting, not in workflow definitions, copied examples or chat messages.

Plan rotation with overlap only where the provider allows it, so that a replacement credential takes effect before the old one is retired. Keep a documented way to revoke a credential that is no longer needed.

Check the permission model and consent

For Microsoft APIs, the choice between application and delegated permissions affects whether a person must sign in. Application permissions are granted directly to an application; delegated permissions are granted to a signed-in user. Confirm which model the API supports and whether the workflow can meet its sign-in requirements.

Microsoft API permissions are configured in the Microsoft Entra app registration. Application permissions require administrator consent to function, so include that approval in the integration decision rather than treating it as a later setup detail.

The permission model also constrains the authentication flow: Microsoft application permission tokens are obtained through the client credentials grant, while delegated permission tokens use delegated flows such as authorisation code or on-behalf-of. Check that the provider's supported flow fits how the workflow runs; a scheduled process with no user present may not suit a delegated model.

Key Security Practices from Australian Cyber Guidelines

Design secrets management for the people and systems using it

OWASP identifies storage, provisioning, auditing, rotation and management as connected practices for controlling access and reducing the risk of leaks. Include API keys, database credentials, identity and access permissions, SSH keys and certificates in the inventory where they apply.

Centralisation can improve control, but teams may consume and manage secrets differently. OWASP recommends standardising how teams interact with their chosen solutions; that can mean more than one storage service, provided the approach remains maintainable and usable during an incident.

A central secrets service may itself depend on a powerful primary credential, such as a cloud management credential. Plan how that credential is protected separately, so access to the secrets store does not rely on an unprotected root credential in the same place.

Include availability in the decision

A secrets store is part of the workflow's operating path. OWASP advises choosing technology robust enough to serve application traffic reliably: poor performance can reduce the availability of dependent applications or increase their start-up times.

Consider incident response as well as normal operation. Teams may need credentials provisioned quickly to recover services, so a process that makes secrets difficult to access during an incident can slow recovery even if the underlying workflow authentication is sound.

Check the failure path

Inspect normal and error logs for tokens, headers and payloads containing secrets or sensitive data. Log a request ID and outcome instead of full authentication material. Set alerts for failed scheduled runs and expiring credentials; a rotated key is not a success if the overnight job stops processing.

Keep an owner, scope, expiry and recovery method for every connection. Review them when an employee leaves, a vendor changes or the workflow's purpose expands, and record who is accountable for each review.