使用Bootstrap代币的办公室加载项以获取其他令牌
我们需要从加载项来调用图形以外的其他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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
关于是否应将访问令牌发送给客户还是在客户上存储的“收到的智慧”在过去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.