A safe Microsoft connection starts by choosing delegated or app-only access, registering the correct tenant audience, and keeping tokens out of browsers and business records.
Delegated permissions let the app act within both the signed-in user's rights and the granted scopes. Application permissions let a service act without that user and generally require administrator consent, so they are not a shortcut for normal account connection.
Decide whether the application supports one organization, many organizations, or personal Microsoft accounts. Register exact redirect URIs, use the authorization-code flow with PKCE where appropriate, and validate state and nonce values.
Reading mail, modifying mail, and sending mail use distinct Microsoft Graph permissions. Ask for the least privileged set the product needs and show customers why each permission is required before redirecting to consent.
Encrypt refresh material, rotate it according to Microsoft identity responses, and never log tokens. Conditional Access, administrator policy, password changes, and revoked consent can all force a fresh user or administrator decision.
Delegated access acts for a signed-in user and is limited by both the app's scopes and that user's rights. Application access uses the app's identity without a signed-in user and normally carries broader administrative consequences.
No. Consent requirements vary by permission and tenant policy. The integration must handle user consent, administrator consent, and refusal without assuming one universal flow.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.