The target Google OAuth flow proves user consent, binds the callback to the initiating workspace, and stores server-side credentials under the user's API-project grant rather than pretending each product token is independent.
Configure the Google Cloud project, application identity, authorized domains, privacy disclosures, and exact redirect URIs. Select scopes from the features the user can see, not from what might be convenient later.
Create a high-entropy state value tied to the workspace, user, provider, and expiry. Exchange the returned authorization code on the server and reject reused, expired, or mismatched intents.
Sensitive and restricted Google scopes carry additional review. Several Gmail mailbox scopes are restricted, and server storage or transmission of restricted-scope data can require a security assessment. DewEngine cannot waive this process.
Encrypt refresh material, lock refresh and rotation across the Google user and API project, and treat invalid_grant as a grant-wide reconnect state. A local product unlink must not revoke a shared grant by surprise; upstream revocation invalidates the project's combined scopes and clients for that user and needs an explicit blast-radius warning before retained credentials and derived data are deleted under policy.
No. The user authenticates with Google and grants scopes; the application receives tokens representing that authorization, not the Google password.
It can request incremental authorization, but Google can combine the new scopes with every scope that user already granted to the API project, including through other clients. Treat scope expansion and its revocation blast radius as product, security, and compliance changes.
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.