Every connection in Malveon is an OAuth grant you authorize and can revoke. This page covers the scopes Malveon requests, how the flow is protected, and how the resulting tokens are stored.
The OAuth flow
Connecting a tool is a standard OAuth authorization-code exchange with two safeguards. Malveon sends a signed state value with the authorization request and checks it on the callback, so a forged or replayed callback is rejected before anything else happens. It then exchanges the code for a token, encrypts the token, and stores it.
What each scope grants
- GitHub: repository, organization, and user-profile access. Broader than read-only at the token level; Malveon behavior is read-oriented (metadata, not source files).
- Jira: read access to work items and users.
- Linear: read access to issues and project data.
- Confluence: read access to pages, spaces, and search.
- Notion: access to the pages and databases you share with the integration.
- Google Docs: read-only access to documents and Drive metadata.
- Microsoft Teams: read access to channel and chat messages.
- Slack: a dedicated connection scoped to the channels you choose.
Token storage
An OAuth token is a credential. Malveon encrypts every stored token at rest with AES-256-GCM before it touches the database, so a database dump on its own exposes no usable token. You can revoke any connection from your settings, which invalidates the token immediately.
Webhook verification
Incoming webhooks are verified with a per-provider HMAC signature before processing; a mismatch is rejected with a 401 before the body is parsed. This is fully in place for Slack, GitHub, Jira, and Linear. Microsoft Teams, Confluence, and Google Docs do not sign with HMAC by default, so those connections rely on other validation. We call that distinction out rather than claiming uniform signed webhooks.