Decrypting .rpmsg blob using delegated permissions

Delegated access with Microsoft Entra ID and the Microsoft Information Protection (MIP) SDK requires both the app and the user to be authorized for the specific protected content. Having an access token and delegated scopes is necessary but not sufficient to decrypt third‑party encrypted mail.

Key points from the platform behavior:

1. Delegated access is always “user + app”
   • Delegated access means the app acts on behalf of a signed‑in user.
   • The client app is authorized via scopes (delegated permissions), and the user is authorized by the resource (for example, the protection service that owns the encrypted content).
   • If either the app does not have the correct scope or the user is not allowed to access the resource in the sender’s tenant, the call fails.
   • This is by design: a token with delegated scopes does not override the sender tenant’s access rules.
2. Why Outlook/Adobe can open the message but the webhook cannot
   • Outlook and other clients open the protected message in the context of the actual recipient user, using the protection service and trust relationships that exist between tenants.
   • Your webhook runs as a separate application that is trying to inspect/decrypt content via MIP SDK using delegated tokens. The protection service in the sender’s tenant validates both:
     • The app (is this app allowed to consume this content?), and
     • The user (is this user a valid recipient / has rights to this content?).
   • When the protection service reports that the email receiver “does not exist in the sender’s tenant,” it reflects that the cross‑tenant authorization for that user/app combination is not satisfied. The delegated token alone does not grant cross‑tenant decryption rights to your app.
3. MIP SDK behavior for .rpmsg
   • For .rpmsg (Purview Message Encryption) content, MIP’s MsgInspector only supports decryption for inspection scenarios.
   • The inspection API:
     • Decrypts the embedded message.rpmsg and returns plaintext body and attachment byte streams.
     • Does not output a usable .MSG or re‑protected file.
     • Does not support publishing or reprotection for message.rpmsg.
   • If the protection service denies access (for example, because the user/app is not authorized in the sender’s tenant), the MIP SDK cannot override that.
4. Delegated handler requirements in MIP
   • For delegated consumption/publishing with MIP SDK, specific delegated permissions are required on the protection service:
     • Content.DelegatedReader for delegated consumption.
     • Content.DelegatedWriter for delegated publishing.
   • Even with these, the protection service still enforces the sender’s policy and user authorization. The SDK cannot bypass tenant‑level or policy‑level restrictions.
5. Why this feels like a “hard limitation”
   • The limitation is intentional: it prevents any third‑party app that can obtain a delegated token from decrypting arbitrary protected mail across tenants.
   • Delegated access is meant for “user working with their own resources or resources they can access,” not for broad cross‑tenant inspection of encrypted content.
   • For DLP/inspection scenarios, Microsoft typically recommends:
     • Application‑only access patterns where the protection/DLP service is explicitly trusted and configured, or
     • Using supported DLP integrations that are part of Microsoft’s own services.
6. Practical implications for a third‑party app
   • If the sender’s tenant has not explicitly allowed your app/service as a trusted consumer of their protected content, your app will not be able to decrypt that content via MIP, even if the recipient user can open it in Outlook.
   • There is no supported way in MIP SDK to “force” decryption of third‑party encrypted mail purely because a delegated access token exists.
7. Alternatives within the documented model
   • Use delegated access only for scenarios where the user and app are clearly authorized by the resource owner (for example, within the same tenant or where explicit trust is configured).
   • For cross‑tenant DLP/inspection needs, consider:
     • Application‑only access patterns where the resource owner (sender tenant) onboards and trusts the inspecting service.
     • Built‑in Microsoft DLP and compliance features rather than a generic third‑party decrypt‑and‑inspect pipeline.
   • For email containers:
     • If a valid MSG file is available and the user has rights, MIP File SDK can remove protection from MSG files and output a usable file.
     • For .rpmsg, only inspection (plaintext streams) is supported; publishing/re‑protection and MSG reconstruction are not supported.

In summary, the behavior observed is consistent with the delegated access and MIP SDK design: access tokens with delegated scopes do not grant unrestricted decryption of third‑party encrypted mail. Decryption is constrained by the sender tenant’s policies and the supported inspection‑only model for .rpmsg in MIP SDK.

References:

• Understanding delegated access
• Refresh tokens in the Microsoft identity platform
• Nested app authentication FAQ
• Concept - Delegation in the MIP SDK
• File SDK email message file processing