SharePoint Add-In retirement in Microsoft 365

While I understand the need to move towards a more modern tech stack, I believe the need to replace Remote Event Receivers by webhooks can lead to a lower security for ISV. Let me explain why.

Using RER and the addin model, the incoming notification contained a token that was contextualized to the user. The addin was able to consume the token and get access to the intersection of what the user can access to, and what the addin was granted to access.

As ISV, it was very convenient, because the permission of the addin was de facto bound the call context. Customer segregation was easier, with a “on behalf of” flow (not technically oauth OBO flow, but the idea is similar).

Using webhooks, we only get a notification that says where something happens. The webhook job then must get the changed data using an app-only authentication flow. Such flow adds some extra challenges (as ISV): how to authenticate onto our multiple customer tenants, preventing potential exposure of one customer data to another? How can we limit the field of action of a potential malicious user that may find vulnerability? How can we justify to the customer we need such high privileged access just to update a field in a document automatically?

In our company we implemented a very complex set of services, just to reduce this risk, with a quite complex customer onboarding process. Instead of having one global multi-tenant application in our tenant, we ask our customers to register a customer dedicated to their tenant, with secrets dedicated to the customer. In our system, every customer has its own certificate to auth against only its own tenant. This is far from perfect. And I didn’t even talk about the need to maintain a list of a webhook subscription to refresh the subscription every few weeks. A little nightmare as an ISV.

That said, my wishlist from an ISV perspective, is to extend the webhooks to:

• Support synchronous events. Computing a field to match a business rule was a piece of cake with RER: read the item fields, compute the rule and fill the changes property in the response. SharePoint handles the rest. With webhooks, the flow is awful. First we have to wait for the notification, then process the rule, update the item (which implies getting the customer specific secret, get an app only token, to perform the operation). Detect the new notification as a reentrance notification (because the webhook update will trigger update too) and discard it.
• Allow webhooks to use delegated auth
• Give better control of webhook expiry to simplify the subscription refresh

I hope Microsoft will hear the ISV ecosystem which tends to understand the depreciation, but is expecting the new stack to not reduce our capacity to build great products.

Thanks