No-Code SaaS Automation Platform  ·  View 20 of 21  ·  Assurance

Identity and Access Flow

Grant, store, exchange, use — and then the 401 that ends it, which is where this flow earns its place.

Editable source SVG draw.io All views
Author Author API Custody Key service Provider OAuth Governor Step runner 1. connect account 2. narrowest scopes 3. consent screen 4. approves 5. grant code 6. exchange and store 7. encrypt, workspace key 8. connection id only 9. effect and key 10. run-scoped token 11. single-flight refresh 12. short-lived token 13. call with token 14. 401 revoked 15. mark dead 16. non-retryable Identity and Access — Grant, Use, and Death The refresh token never leaves custody, and the runner never holds a credential it could reuse - only a token scoped to one connection and one run. v 1.0 · owner Integration Platform Architecture · date 2026-10

What this view proves

  • The Author API never sees the credential: it hands the grant code to custody and gets back a connection id. That keeps the long-lived material inside one zone from the first second.
  • Refresh is single-flighted per connection. Without it, a thousand concurrent runs on one connection produce a thousand refreshes and a provider-side refresh-token rotation race — a self-inflicted credential death.
  • The flow deliberately ends on the revocation path, because that is the branch journey 05 is about and the one most identity diagrams omit.

Assumptions

  • Revocation from the platform takes effect within 60 s, and credential-use audit is retained 7 years.
  • Tokens issued to the governor are scoped to one connection and one run, so their useful lifetime is the run's deadline rather than the provider's token TTL.

Trade-off

  • Caching the exchanged token for the run's duration cuts a cross-account hop from every step and widens the revocation window to that run's deadline. Taken knowingly; the 60-second revocation promise is about new runs.