We just started using Jira for managing support tickets and need help setting it up with our Office 365 email system. Our support email is a shared mailbox with a license, but we disabled login access for security reasons. This means Jira can’t get the tokens it needs to read emails and create tickets automatically.
I think blocking login on shared mailboxes is pretty normal for security. I found a workaround that involves forwarding emails from our support mailbox to a different licensed mailbox. Not sure if this second mailbox should be a regular user account or another shared mailbox.
We want to use OAuth 2.0 authentication so Jira can get tokens from Azure AD through the Graph API. Does this plan make sense? What type of mailbox should we use for the second one - a regular user mailbox or shared mailbox? Also, should we remove MFA requirements for this second mailbox?
Been running a similar setup for about 18 months now and there’s one aspect others haven’t mentioned - mailbox delegation. Instead of forwarding emails, you can grant your service account full access permissions to the shared mailbox directly through PowerShell. This eliminates the forwarding step entirely and reduces complexity. The service account can then use OAuth to authenticate and read directly from the shared mailbox using Graph API calls. We found this approach more reliable than forwarding since there’s no risk of message loss or header corruption. For the service account itself, definitely go with a regular user mailbox and use client credentials flow with a certificate. Make sure to set the account password to never expire and document the certificate renewal process since that’ll bite you in a year or two when it expires unexpectedly.
Your approach with forwarding is solid but I’d recommend going with a dedicated service account instead of a shared mailbox for the OAuth connection. We implemented this exact setup about 6 months ago and found that service accounts work much more reliably with Graph API authentication. Keep the MFA enabled on the service account but configure it to use certificate-based authentication rather than interactive login. This gives you the security benefits without the token refresh headaches. One thing to watch out for is making sure your forwarding rules don’t create loops if Jira sends any automated responses back. Also verify that the service account has the proper Mail.Read permissions in Azure AD and consider setting up monitoring to catch any authentication failures early.
we had similar setup issues last year. ended up using a regular user mailbox for the oauth connection since shared mailboxes can be tricky with api access. keep mfa enabled but use app passwords or certificate auth instead - removing mfa completly isnt great for security. make sure the forwarding user has proper graph permissions too
I’ve been through this integration process twice with different organizations and can confirm your forwarding strategy will work. However, consider the mailbox licensing implications - you’ll need a full Exchange Online license for the destination mailbox to support OAuth properly, not just a basic license. We initially tried using an unlicensed mailbox and ran into permission issues with the Graph API calls. For the authentication piece, I’d suggest setting up application permissions rather than delegated permissions in Azure AD since you’re dealing with automated processes. This approach eliminates the need for interactive login altogether and works better for long-term maintenance. One gotcha we encountered was email formatting - make sure Jira can parse forwarded emails correctly since the forwarding process sometimes adds headers that can interfere with ticket creation rules.
just dealt with this nightmare myself lol. honestly the forwarding thing works but gets messy quick. what we did was create a basic user account (not shared) specifically for jira integration and gave it only the perms it needs in exchange admin. dont disable mfa completely - use app-only auth with certificates like others mentioned. way cleaner than dealing with token refreshes every few months