DonutworkHelp Center
Sentinel
Donutwork documentation

Delegated Email Magic Links

Passwordless authentication architecture, controls, and responsibilities for third-party applications.

Delegated Email Magic Links

Sentinel can deliver a single-use sign-in link for a registered user to an exact callback owned by your application. Donutwork verifies the email proof; your backend remains responsible for deciding access and creating the application session.

Trust model

The flow combines two independent values:

  • The email contains a random, single-use token and transaction identifier.
  • Your backend retains a private PKCE code_verifier; only its S256 challenge is sent when delivery is requested.

Possession of the email URL alone is therefore insufficient to verify the transaction through another client. The proof is also bound to the company and API key that requested it.

User → Application Y → Donutwork request API
                       ↓ email
User browser → exact Y callback → Y backend → Donutwork verify API
                                             ↓
                                  identity + Sentinel advice

Application responsibilities

Your application must:

  1. Generate and retain the PKCE verifier and anti-CSRF state server-side.
  2. Request only a callback URL registered in Sentinel settings.
  3. Compare state and immediately scrub token parameters from browser history.
  4. Call verification from the backend with the same bearer API key.
  5. Apply the returned Sentinel advice according to your policy and create its own session.

Advisory risk decision

Sentinel reports allow, challenge_mfa, or deny advice. It does not create or revoke the third-party application's session automatically.

Lifecycle and abuse controls

  • Unknown users receive the same accepted response as known users, reducing account enumeration.
  • Only one active transaction exists per user and requesting API key; a resend invalidates the previous link.
  • A transaction is consumed atomically after one valid verification and expires after the configured lifetime.
  • Request cooldown, request window, maximum requests, and verification attempts are configurable.
  • A user must be active and have an enabled email external account whose value still matches the request-time fingerprint.

For payloads, responses, errors, and integration details, see the IDP Email Magic Links API reference.

On this page