将 SSO 与 Office.js Excel 加载项一起使用 - 如何设置令牌的受众?
Using SSO with Office.js Excel add-in - how to set the audience for the token?
TL;DR - 有没有办法从 Office.js 中的 the new SSO stuff 获得具有自定义受众(可能还有权限)的不记名令牌?
详情-
我们正在尝试将新的 SSO 内容用于 Office.js 加载项,但我们 运行 遇到了问题,即来自 OfficeRuntime.auth
的不记名令牌设置了我们的加载项的 GUID 受众;我们想像以前使用 MSAL 一样设置不同的受众(我们的 API 应用程序),但似乎没有任何选择。我们使用 getAccessToken
来自 OfficeRuntime.auth
:
const token = await OfficeRuntime.auth.getAccessToken({
allowSignInPrompt: withUI,
allowConsentPrompt: withUI
});
(withUI
只是一个 true
/false
标志,我们根据显示 UI 是否正常发送函数。)
options documentation 没有显示我们可以看到的 "scope" 或 "audience"(或 "authority")的选项。当然这些东西都是预览版,所以可能是 "it's just not in there yet."
的问题
我们的设置是:
+−−−−−−−−−−−−−−−−−+
| 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 对我来说是新的(尽管对团队的其他成员来说不是)。
此行为是设计使然。对于 Office SSO,Web API 必须是与加载项相同的域和 AAD GUID。
如果您想将它们分开,那么您找到的解决方法似乎很不错。 (我很惊讶你找到了方法。)
<highly speculative>
您可能还想尝试将加载项的 GUID 放入 API 的 AAD 注册的 Authorized Client Applications 部分。
</highly speculative>
事实证明这是一个非常愚蠢的错误:我们不得不在 API 项目中指定受众和权限(在问题的代码中),但事实证明我们是 已经在API项目中指定它们——它们在appsettings.json
中定义(具有不同的值)。所以我们添加的代码只是用正确的值覆盖了它们。
更改 appsettings.json
的 Audience
和 Authority
设置,并删除覆盖它们的代码,效果很好。所以它已经有点硬编码(或者至少不是通过 AD 控制),只是在配置文件而不是代码中。
TL;DR - 有没有办法从 Office.js 中的 the new SSO stuff 获得具有自定义受众(可能还有权限)的不记名令牌?
详情-
我们正在尝试将新的 SSO 内容用于 Office.js 加载项,但我们 运行 遇到了问题,即来自 OfficeRuntime.auth
的不记名令牌设置了我们的加载项的 GUID 受众;我们想像以前使用 MSAL 一样设置不同的受众(我们的 API 应用程序),但似乎没有任何选择。我们使用 getAccessToken
来自 OfficeRuntime.auth
:
const token = await OfficeRuntime.auth.getAccessToken({
allowSignInPrompt: withUI,
allowConsentPrompt: withUI
});
(withUI
只是一个 true
/false
标志,我们根据显示 UI 是否正常发送函数。)
options documentation 没有显示我们可以看到的 "scope" 或 "audience"(或 "authority")的选项。当然这些东西都是预览版,所以可能是 "it's just not in there yet."
的问题我们的设置是:
+−−−−−−−−−−−−−−−−−+ | 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 对我来说是新的(尽管对团队的其他成员来说不是)。
此行为是设计使然。对于 Office SSO,Web API 必须是与加载项相同的域和 AAD GUID。
如果您想将它们分开,那么您找到的解决方法似乎很不错。 (我很惊讶你找到了方法。)
<highly speculative>
您可能还想尝试将加载项的 GUID 放入 API 的 AAD 注册的 Authorized Client Applications 部分。
</highly speculative>
事实证明这是一个非常愚蠢的错误:我们不得不在 API 项目中指定受众和权限(在问题的代码中),但事实证明我们是 已经在API项目中指定它们——它们在appsettings.json
中定义(具有不同的值)。所以我们添加的代码只是用正确的值覆盖了它们。
更改 appsettings.json
的 Audience
和 Authority
设置,并删除覆盖它们的代码,效果很好。所以它已经有点硬编码(或者至少不是通过 AD 控制),只是在配置文件而不是代码中。