Using SSO with Office.js Excel add-in - how to set the audience for the token? - single-sign-on

Question

TL;DR - Is there a way to get a bearer token with a custom audience (and perhaps authority) from the new SSO stuff in an Office.js?
Details -
We're trying to use the new SSO stuff for an Office.js add-in, but we're running into the problem that the bearer token from OfficeRuntime.auth sets the audience to the GUID for our add-in; we want to set a different audience (our API application) like we used to with MSAL, but there doesn't seem to be any option for that. We're using getAccessToken from OfficeRuntime.auth:
const token = await OfficeRuntime.auth.getAccessToken({
allowSignInPrompt: withUI,
allowConsentPrompt: withUI
});
(withUI is just a true/false flag we send the function this is in depending on whether showing a UI is okay.)
The options documentation doesn't show an option for "scope" or "audience" (or "authority") that we can see. Granted this stuff is all preview, so it could be a matter of "it's just not in there yet."
Our setup is:
+−−−−−−−−−−−−−−−−−+
| Browser / Excel |
+−−−−−−−−−−−−−−−−−+
| |
| +−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−+
| | Our add−in |<−−−−−>| Server w/ our API |<−−−−−>| Microsoft Graph |
| +−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−+
| | ^
+−−−−−−−−−−−−−−−−−+ |
v
+−−−−−−−−−−−−−−−−−+
| Azure DB |
+−−−−−−−−−−−−−−−−−+
Our add-in is set up as an Azure application and, separately, our API server is set up as an Azure application. The add-in has access rights to the API; the API has access rights to the various things it needs to satisfy API calls. That way, the relationships between the pieces are visible in the Azure configuration.
When we found we couldn't use the token from SSO, we looked at its contents and that's when we realized the audience wasn't what we wanted. For now we're working around it by adding the add-in's audience and authority to the options in the API project's authentication step:
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
Configuration.Bind("AzureJwt", options);
// These next two are the ones we had to add to make it work
// when we realized there was an audience problem
options.Audience = "guid-for-the-add-in";
options.Authority = "https://login.microsoftonline.com/relevant-guid-here/v2.0";
});
But that feels like a workaround rather than a solution; our Azure config doesn't represent what's going on, we have hardcoded authentication instead.
Apologies if some of my terminology is off. Azure is new for me (though not for another member of the team).

Answer 1

This behavior is by design. For Office SSO, the web API has to be the same domain and AAD GUID as the add-in.
If you want to keep them separate, then the workaround you've found seems pretty good. (I'm surprised that you found a way.)
<highly speculative>
You might also want to try putting the add-in's GUID in the Authorized Client Applications section of the API's AAD registration.
</highly speculative>

Answer 2

It turned out to be a really silly mistake: We were bothered by having to specify the audience and authority in the API project (in the code in the question), but it turns out we were already specifying them in the API project — they were defined (with different values) in appsettings.json. So the code we added just overwrote them with the correct values.
Changing appsettings.json's Audience and Authority settings, and removing the code overriding them, worked just fine. So it was already a bit hardcoded (or at least not controlled via AD), just in a config file rather than code.