使用Bootstrap代币的办公室加载项以获取其他令牌

发布于 2025-01-27 15:40:48 字数 43 浏览 4 评论 0原文

我们需要从加载项来调用图形以外的其他API(例如动态,电源自动化等)。

We have a requirement to call other APIs other than graph(like Dynamics, Power Automate etc.,) from our Add-in. All examples in Office Add-in Samples suggest to use bootstrap token and then exchange it to get tokens for subsequent APIs and make calls on the server. This forces all communication from our Add-in to be proxied via our server. This can be a unncessary performance bottle-neck. Can we not send the OBO tokens back to our client side Add-in and call other services directly from the client? Is there a known security issue with this approach?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

一城柳絮吹成雪 2025-02-03 15:40:49

关于是否应将访问令牌发送给客户还是在客户上存储的“收到的智慧”在过去10 -15年中发生了波动,但是近年来,摆钟已经果断地决定了访问令牌不应在客户身上的想法。 。客户对服务器通信比服务器到服务器通信更容易受到伤害,因为有多种攻击客户和欺骗用户的知名方法。同时,坏演员不知道何时进行服务器到服务器通信,并且在通信的任何一端都可以访问服务器计算机要困难得多。

The "received wisdom" about whether access tokens should be sent to clients or stored on clients has fluctuated over the last 10 -15 years, but in recent years the pendulum has swung pretty decisively to the idea that access tokens should not be on the clients. Client-to-server communication is much more vulnerable than server-to-server communication, because there are a wide variety of well-known ways to attack clients and trick users. At the same time, bad actors don't know when server-to-server communication is going to take place and it is much harder to get access to the server computers on either end of the communication.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文