I'm evaluating Fireflies.ai for my team's Microsoft Teams meeting capture and transcription. The integration process is not as straightforward as the marketing suggests. I've hit a persistent 'authentication failed' error during the OAuth flow when trying to connect the Fireflies app within Teams.
Here's my exact workflow and where it breaks:
* I add the Fireflies.ai app from the Teams App Store.
* I click "Sign in with Microsoft" or the equivalent button.
* It redirects to the Microsoft login page. I enter my corporate credentials (M365, global admin role for testing).
* It asks for permissions (read user profile, read all chat messages, etc.). I accept.
* It redirects back to Teams and displays "Authentication failed. Please try again."
I've ruled out the obvious:
* Admin consent is granted in our Azure AD enterprise applications.
* Our conditional access policies aren't blocking it (tested from a compliant device).
* Fireflies subscription is active on a paid plan.
My specific questions for the community:
* Is there a known conflict with specific M365 tenant security defaults or sensitivity labels?
* Has anyone resolved this by modifying the API permissions requested by the Fireflies Azure AD app?
* Are there firewall or network restrictions (specific endpoints) that need whitelisting beyond the standard Microsoft endpoints?
I need a reproducible fix, not "try clearing your cache." This is blocking a procurement evaluation on usability and integration overhead.
pp25
page 18 is where the traps are
I ran into a similar wall last quarter! For us, it turned out to be a specific API permission mismatch. Even though admin consent was granted, Fireflies was requesting a permission that our tenant policy specifically blocks for third-party apps, like "ChannelMessage.Read.All".
You mentioned checking the enterprise applications, but did you compare the exact permissions Fireflies is requesting in the Azure AD consent screen against your tenant's app permission policies? Sometimes the admin consent step looks successful, but a subset of the requested scopes gets silently rejected.
A quick fix that worked for my team was having our admin explicitly add the Fireflies app registration (found via the application ID) directly in the Azure portal under "Enterprise applications" and then re-do the admin consent from there, rather than through the Teams OAuth flow. It forced a fresh token.
On your question about sensitivity labels, I'm curious about that too. Could overly restrictive labels on the Teams meeting or channel interfere with the app's access?
Thanks for the detailed breakdown! I'm also trying to set this up soon, so this is super helpful to read. Just to clarify, when you say you ruled out admin consent, does that mean you saw the app listed as fully consented in the Azure portal under "Enterprise applications"? I've read that sometimes the status can look green but there's still a hidden token issue.
Could it possibly be related to multi-factor authentication? I know some OAuth flows get picky if MFA is required but the app expects a different grant type.
Oh man, that "authentication failed" after the consent screen is the worst. Been there with other M365 app integrations. Since you're a global admin and you've checked conditional access, I'd zoom in on the API permissions list itself.
When you said you ruled out admin consent, did you check if the consent was for *all users* or just for yourself? I've seen cases where an admin grants consent during their own login flow, but the app's multi-tenancy settings in Azure AD are misconfigured, so it doesn't propagate properly for the organization. It looks consented from your view, but the service principal isn't fully created.
Also, seconding the note about MFA possibly breaking the flow, but that's usually a different error. Your scenario screams "silent permission rejection." Can you check the audit logs in Azure AD under "Sign-ins" filtered by the Fireflies app? Sometimes the failure reason is logged there, like "invalid client secret" or "redirect URI mismatch," even if the UI just gives you a generic fail.
If it's not measurable, it's not marketing.