WebHooks are user-defined HTTP callbacks. The problem they intend to solve is “pushing” information to you. Pushing is an unusually complex problem to solve. We’ve gotten so used to server-based applications, such as Office 365 resources, to expose a REST API that you “pull” information from.
Your application makes an HTTP call to find out if there is anything new. Pull works, but has some distinct disadvantages. It’s certainly not responsive enough for real-time operations, such as chat. And more importantly, it puts an undue load on both your application and the server.
At its heart, Office365 facilitates collaboration. Sure, there are tools like Word, Excel, etc. But the bottom line is that Office365 helps you manage information, and it helps you do so between teams.
With that in mind, Microsoft introduced the concept of Office 365 Groups. A group is exactly what it sounds like: a number of people, a group, who want to work together. You create this group, and “hang” different things on the group.
Message level security encrypts request / response messages using WS-Security specifications. It encloses security credentials and claims with every message. Each message either signed or encrypted.
Message Security provides end-to-end channel security and is independent of transport protocol. In short mutual authentication and message security are delivered at the message level.
The default client credential type for NetTcpBinding is Windows Authentication. For Windows Authentication to work both client and server must be in the same domain, or mutually trusting domains (which in your case you do not have).
If both client and server were on the same domain, WCF would handle the mechanics of Windows Authentication “behind the scenes”. And when both client and server are on the same machine they are effectively within the same domain, so Windows can use its own mechanisms to handle the encryption and decryption. It will only do this within mutually trusting domains, though.