Использование единого входа с Office. js Надстройка Excel - как настроить аудиторию для токена?

Question

TL; DR - есть ли способ получить токен на предъявителя с пользовательской аудиторией (и, возможно, авторитетом) от нового материала единого входа в офисе. js?

Подробности -

Мы пытаемся использовать новый SSO для Office. Надстройка js, но мы сталкиваемся с проблемой, что токен на предъявителя из OfficeRuntime.auth устанавливает аудиторию на GUID для нашей надстройки; мы хотим установить другую аудиторию (наше приложение API), как мы привыкли к MSAL, но, похоже, для этого нет никакой возможности. Мы используем getAccessToken из OfficeRuntime.auth:

const token = await OfficeRuntime.auth.getAccessToken({
    allowSignInPrompt: withUI,
    allowConsentPrompt: withUI
});

(withUI - это просто флаг true / false, мы отправляем функцию, в которой это зависит о том, хорошо ли показывать пользовательский интерфейс.)

Документация по не показывает опцию для "видимости" или "аудитории" (или "авторитета"), которую мы можем видеть. Конечно, все это предварительный просмотр, так что это может быть вопрос «его просто нет».

Наша настройка:

+−−−−−−−−−−−−−−−−−+
| Browser / Excel |
+−−−−−−−−−−−−−−−−−+
|                 |
|   +−−−−−−−−−−−−−+       +−−−−−−−−−−−−−−−−−−−+       +−−−−−−−−−−−−−−−−−+
|   | Our add−in  |<−−−−−>| Server w/ our API |<−−−−−>| Microsoft Graph |
|   +−−−−−−−−−−−−−+       +−−−−−−−−−−−−−−−−−−−+       +−−−−−−−−−−−−−−−−−+
|                 |                 ^
+−−−−−−−−−−−−−−−−−+                 |
                                    v
                          +−−−−−−−−−−−−−−−−−+
                          |     Azure DB    |
                          +−−−−−−−−−−−−−−−−−+

Наша надстройка настроена как приложение Azure и, отдельно, наш сервер API настроен как приложение Azure. Надстройка имеет права доступа к API; API имеет права доступа к различным вещам, необходимым для удовлетворения вызовов API. Таким образом, отношения между частями видны в конфигурации Azure.

Когда мы обнаружили, что не можем использовать токен из SSO, мы посмотрели на его содержимое, и именно тогда мы поняли, что аудитория не была ' т то, что мы хотели. Сейчас мы работаем над этим, добавляя аудиторию и полномочия надстройки к параметрам на этапе аутентификации проекта API:

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";
    });

Но это похоже на обходной путь, а не решение; наша конфигурация Azure не отражает происходящее, вместо этого мы используем жестко запрограммированную аутентификацию.

Извиняюсь, если какая-то из моих терминов отключена. Azure для меня новость (но не для другого члена команды).

Answer 1

Это оказалось действительно глупой ошибкой: нам надоело указывать аудиторию и полномочия в проекте API (в коде в вопросе), но оказывается, что мы уже указав их в проекте API - они были определены (с разными значениями) в appsettings.json. Поэтому код, который мы добавили, просто переписал их с правильными значениями.

Изменение настроек appsettings.json * Audience и Authority и удаление кода, переопределяющего их, работали просто отлично. Так что он уже был немного закодирован (или, по крайней мере, не контролируется через AD), просто в файле конфигурации, а не в коде.

Answer 2

Такое поведение предусмотрено дизайном. Для единого входа Office веб-API должен быть таким же доменом и идентификатором AAD GUID, что и надстройка.

Если вы хотите разделить их, то найденный обходной путь кажется довольно хорошим. (Я удивлен, что вы нашли способ.)

<highly speculative> Вы также можете попробовать добавить GUID надстройки в раздел Авторизованные клиентские приложения регистрации API AAD. , </highly speculative>