Security requirements for actionable messages in Office 365
Securing actionable email is simple and easy. There are two phases within the end-to-end experience that impose security requirements on your service when supporting actionable messages with Office 365. The phases and their corresponding requirements are as follows.
- Send phase: The pre-requisites for your service to send actionable messages are as follows:
- If you're using actionable email, check that your mail servers are leveraging SPF and DKIM as an additional safeguard against sender email spoofing (majority of mail systems do that already). Note that this does not apply to connector messages.
- Your service must be registered with Microsoft.
- The Action URL must support HTTPS.
- Action processing phase: When processing an action, your service should:
- Verify the bearer token (a JSON Web token) included in the header of the HTTP POST request. Verification can also be done leveraging the sample libraries provided by Microsoft.
- Include Limited Purpose Token from your service as part of the target URL, which can be used by your service to correlate the service URL with the intended request & user. This is optional, but highly recommended.
All action requests from Microsoft have a bearer token in the HTTP
Authorization header. This token is a JSON Web Token (JWT) token signed by Microsoft, and it includes important claims that we strongly recommend should be verified by the service handling the associated request.
||The base URL of the target service, e.g.
||The identity of the user who took the action. For Actionable Messages sent over email,
||The identity of sender of the message containing the action.|
Typically, a service will perform the following verifications.
- The token is signed by Microsoft.
audclaim corresponds to the service's base URL.
With all the above verifications done, the service can trust the
sub claims to be the identity of the sender and the user taking the action. A service can optionally validate that the
sub claims match the sender and user it is expecting.
Please refer to the Microsoft code samples provided below, which show how to do these validations on the JWT token.
Limited purpose tokens can be used to correlate service URLs with specific messages and users. Microsoft recommends that service providers use "limited-purpose tokens" as part of the action target URL, or in the body of the request coming back to the service. For example:
Limited-purpose tokens act as correlation IDs (for e.g. a hashed token using the userID, requestID, and salt). This allows the service provider to keep track of the action URLs it generates and sends out and match it with action requests coming in. In addition to correlation, the service provider may use the limited purpose token to protect itself from replay attacks. For example, the service provider may choose to reject the request, if the action was already performed previously with the same token.
Microsoft does not prescribe how the limited-access tokens should be designed or used by the service. This token is opaque to Microsoft, and is simply echoed back to the service.