Planned capability

Hosted authorization

Connect an end-user account without losing grant ownership

Design delegated account authorization as a recoverable security workflow, not a redirect shortcut. The planned DewEngine surface will correlate the customer user, provider identity, OAuth project or session, requested capability, and connected-account lifecycle before an application receives an account identifier.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

Generic hosted authorization is not released

Authorization on behalf of customer users is planned and not callable outside the isolated development slice. There is no provider-neutral hosted flow for mail, messaging, calendar, QR, or credential-based connections.

Current evidence: The console and control plane implement a Google Calendar development flow with redirect allowlists, expiring intents, state, PKCE, encrypted token staging, bounded exchange recovery, identity checks, and account linking. Gmail is not offered, and fake-provider evidence is not production Google conformance.
Target contract: Create a short-lived intent tied to workspace, customer correlation, provider choice, requested capability, and an exact allowlisted return URI; Validate callback state and provider subject before promoting staged authorization into one tenant-owned connected account; Represent reconnect, consent expansion, disconnect, revocation, and indeterminate exchange as explicit lifecycle transitions
Known limits: Provider grants can be broader than one DewEngine account, and revoking one token may affect every scope or client under the same user and API project; A successful OAuth callback does not prove continuing access, approved production scopes, messaging eligibility, or safe deletion across upstream systems and backups
Release gates: Model Google subject-by-project grant ownership and whole-grant fencing before expanding hosted Google products; Move secret protection to managed KMS, verify upstream revocation, and prove backup-expiry and deletion procedures; Complete provider verification, real-account conformance, customer identity, consent history, and abuse-resistant redirect testing

Flow ownership

Start from a server-created intent

The customer server should request an authorization intent after authenticating its own user. DewEngine returns a short-lived hosted URL, while the browser carries no authority to change workspace, provider, scopes, or return destination. The callback resolves the opaque intent and sends only bounded success or recovery state back to the application.

Keep workspace and customer correlation out of editable query parameters
Expire unused and partially completed intents through durable cleanup

Implementation safeguards

Stage secrets until identity is verified

Authorization material should first enter encrypted staging linked to the intent. The service validates state, PKCE, issuer, audience, verified provider subject, and requested product before attaching it to an account. If callback completion crashes, recovery must reuse committed markers instead of repeating a one-time code exchange whose outcome is uncertain.

Never place provider tokens in redirect URLs or browser storage
Reject a callback that resolves to a different provider subject

Grant topology

Do not pretend every token is independent

Google authorization, for example, combines grants by user and API project, so separate product accounts can share upstream consequences. Other providers use page assets, organizations, device sessions, or phone identities. The account model must preserve that topology so scope changes, revocation, and deletion fence every dependent capability together when required.

Store a provider-specific grant owner above account capabilities
Explain the blast radius before a customer confirms disconnection

Recovery experience

Turn auth failure into a precise next action

Expired intent, denied consent, invalid callback, transient token exchange, provider mismatch, revoked access, and missing production approval are different states. The hosted page should give the end user a safe retry or return path while the server receives a stable error code. Unknown exchange outcome must not invite an automatic second exchange.

Separate retryable browser steps from operator-only investigation
Preserve sanitized failure evidence without persisting authorization codes

Release qualification

Verify the lifecycle beyond the happy redirect

The release suite needs forged state, replayed callbacks, concurrent tabs, expired PKCE, duplicate provider subjects, scope contraction, refresh races, disconnect during work, and ambiguous revocation. Real provider testing must use the same application registration and redirect origins intended for service operation, followed by deletion and reconnect drills.

Audit every transition without logging tokens or one-time codes
Keep each provider disabled until its own eligibility review clears

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Is hosted Google authorization ready for customer Gmail accounts?+

No. The visible development flow is isolated to Google Calendar evidence. Gmail authorization, restricted-data handling, production OAuth verification, any required security assessment, and a safe shared-grant model remain open.

Why can DewEngine not delete one Google product token independently?+

Google can combine a user's authorization by API project. Revocation may therefore affect the wider grant rather than one local account row, so DewEngine must model and fence the complete grant before promising product-level retirement.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗