[Documentation] NAA is required for sideloaded add-ins with personal Microsoft accounts - unclear in docs

[Skizzy-create]

I wasted two full days on this and I'm honestly frustrated that it wasn't documented clearly anywhere.

The Problem

Building a Word add-in that needed to work with personal Microsoft accounts (gmail.com users signing in with their Microsoft account). Kept getting error 13007 with Office.auth.getAccessToken().

I tried everything:

• Switched between single-tenant and multi-tenant configurations
• Changed signInAudience from AzureADMyOrg to AzureADMultipleOrgs to AzureADandPersonalMicrosoftAccount
• Added every possible redirect URI
• Regenerated client secrets multiple times
• Tested with different accounts - work accounts worked fine, personal accounts always failed
• Read through every piece of documentation I could find

Nothing worked. The error was always the same - 13007 or "User is not signed in".

The Solution (turns out it's simple)

After digging through the NAA samples here, I finally figured it out: for sideloaded add-ins with personal Microsoft accounts, you HAVE to use NAA with MSAL.js. The traditional Office.auth.getAccessToken() just doesn't work reliably for personal accounts in sideloading scenarios.

Once I switched to this approach, it worked immediately:

import { createNestablePublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
  auth: {
    clientId: "your-client-id",
    authority: "https://login.microsoftonline.com/common",
    supportsNestedAppAuth: true  // this flag is critical
  }
};

const pca = await createNestablePublicClientApplication(msalConfig);

That's it. Two days of debugging for a 10-line fix that would have taken 5 minutes if it was documented.

What I'm asking for

Could you add a note somewhere in the NAA samples (like Samples/auth/Outlook-Add-in-SSO-NAA-Identity/) that explicitly says:

If you're building a sideloaded add-in that needs to support personal Microsoft accounts, use NAA. The standard Office SSO approach will likely fail with error 13007.

Or maybe a troubleshooting section that lists:

• Error 13007 with personal accounts → use NAA instead of Office.auth.getAccessToken()
• Azure config needs signInAudience: AzureADandPersonalMicrosoftAccount
• Redirect URI needs brk-multihub://localhost:port

The samples in #924, #832, and #860 show HOW to implement NAA, but none of them explain WHEN you need it vs traditional SSO. That's the missing piece.

Would have saved me a lot of headache. Happy to submit a PR if that helps.

[Skizzy-create]

Just to add - I've already written up detailed documentation while figuring this out over the past two days. If it helps, I can put together a PR with a troubleshooting guide or update the README in one of the existing NAA samples.

Let me know if that would be useful and which sample would be best to update.

[AlexJerabek]

@davidchesnut, could you please take a look and advise?

[davidchesnut]

Hi @Skizzy-create, oof, sorry you spent so much time on that. We're updating the docs to encourage always using NAA (and not the older Office SSO approach which we now consider legacy). There will be a note on the older Office SSO articles recommending to use NAA instead. Maybe we could add to that note the info about personal accounts. Can do the same with the older samples as well.

Does that work?
Thanks!

[Skizzy-create]

Yep, that works — thanks.

If you can add a quick note that personal Microsoft accounts (MSA), especially in sideloaded scenarios, may hit 13007 with Office.auth.getAccessToken() and should use NAA instead, that would solve the main pain point.

Happy to send a PR for the older samples/readmes if you point me to the ones you want updated.

[davidchesnut]

I found the error 13007 issue is already documented here: Troubleshooting errors