Why Robin uses Impersonation instead of Delegate Access

If you've worked with Exchange applications before, you're probably familiar with the different ways to manage permission. Robin's calendar syncing for Exchange connects via User Impersonation.

To understand the differences, here are a few explanations from Microsoft's developer blogs:

Via The importance of EWS Impersonation while using an application account:

Accordingly, Delegate access is a user-manager permission, as it presumes that the user/owner of the mailbox is explicitly granting access. Impersonation, on the other hand, has been designed to support enterprise applications, and is an administratively controlled access methodology that requires no intervention from the mailbox owner
One way to think of the differences is that Impersonation is access for applications, whereas Delegate access is access is for users.

There's also support for better logging out of the box, which gives you much more power to audit how applications access your data:

Note that both Impersonation and Impersonation activity can be logged by both IIS and EWS native logging functionality, providing a full audit trail.

Via Exchange Impersonation vs. Delegate Access:

Exchange Impersonation is used in scenarios in which a single account needs to access many accounts. Line-of-business applications that work with mail typically use Exchange Impersonation.
Delegate access is used in scenarios in which there needs to be a one-to-one relationship between users.

We may support user delegation in the future, but it's unlikely to be the best way to connect.

Additional Reading

Did this article help?