Assessing the Microsoft Entra ID integration available in Jira Cloud Automation

[Gunjan Ahuja]

We are assessing the Microsoft Entra ID integration available in Jira Cloud Automation.

For built-in Entra actions, authorisation creates the Atlassian-A4J Enterprise Application and requests permissions relevant to the selected action. For the custom Entra request action, we provide our own App Registration, client ID and client secret, but Jira still requires a user to sign in and authorise the connection.

Could you please confirm:

1. Do both built-in and custom Entra Automation actions use the OAuth 2.0 authorisation-code flow with delegated Microsoft Graph permissions?
2. Do automation executions operate using the identity and Entra privileges of the user who established the connection?
3. Are Microsoft Graph application permissions or the client-credentials grant supported for custom Entra requests?
4. Is using a dedicated Entra service/integration user supported and recommended for production connections?
5. What events require the connection owner to re-authorise the connection?
Can Entra connections be centrally managed or reused across multiple automation flows?
6. How are refresh tokens stored, protected and renewed by Atlassian Automation?

[Javier Martínez]

Hi Gunjan,

Based on Atlassian's current documentation:

1. Authentication: Both built-in and custom Entra ID actions require an interactive Microsoft authorization step. For custom requests, you register your own Entra application (Client ID/Secret), configure the required Graph permissions, and then authorize the connection through Microsoft.
2. Execution identity: The connection is established by the Microsoft user who authorizes it, so the effective permissions are constrained by the permissions/scopes granted to that connection and the Entra authorization context.
3. Application permissions / client credentials: For Send custom Entra ID request, Atlassian currently documents the interactive authorization process. It does not document support for a pure client-credentials/application-only flow. I would therefore not assume application permissions are supported for this Automation action.
4. Service account: A dedicated Entra integration account can be used to establish the connection and is generally preferable operationally to tying a production integration to an individual employee, provided this aligns with your organization's security policies.
5. Connection reuse: Atlassian currently states that each time you create a flow using Send custom Entra ID request, you need to create a connection. Therefore, this should not be considered a centrally reusable organization-wide connection.
6. Token lifecycle/security: Atlassian handles the OAuth connection after authorization, but its public documentation does not currently describe the implementation details for refresh-token storage, encryption, rotation, or every condition that triggers re-authorization. For a formal security assessment, I would recommend confirming these details directly with Atlassian Support.

Also note that custom requests are currently limited to the graph.microsoft.com service root.

Hope this helps!