---title: "Credentials And Auth"description: "How executor models auth, interactive flows, and actor-scoped credential ownership."--- Auth in executor is not treated as a side detail on the source row. It is modeled as its own layer because auth has different ownership and lifecycle semantics from source bindings and recipe materialization. ## Auth ownership Credentials are scoped to: - workspace- source binding- actor- slot This is important because different users in the same workspace may connect different identities to the same source. ## Auth slots Executor distinguishes where auth is used. Important current slots: - `runtime`- `import` Why this matters: - some integrations use the same auth for both- some need auth only to fetch or generate the materialization- some may eventually need setup/bootstrap-specific auth This is why source auth is more than a single token field. ## Static credentials The common case today is still static auth backed by secret references. Examples: - bearer token- OAuth access token- OAuth refresh token The control plane stores secret refs, not raw secret values inline on the source or credential rows. ## Interactive auth sessions Interactive auth, such as OAuth flows, is modeled separately from stored credentials. That separation exists because: - a pending auth flow has state and lifecycle of its own- it may be tied to an interaction or execution- it is not the same thing as a resolved credential This is why executor has auth sessions and credentials as separate concepts. ## Shareable config vs private state Project config under `.executor/executor.jsonc` is intended to stay portable and committable. Private auth state does not belong in the workspace tree: - actor-scoped credentials- OAuth sessions- refresh leases- secret material That state lives in the local control-plane store under the user's home-scoped executor state instead of the project `.executor/state` directory. ## Why actor scope matters The old one-token-per-source assumption does not hold once: - multiple users share a workspace- each user connects their own Google account, GitHub account, or other external identity Actor-scoped ownership is the durable fix for that. ## The next auth primitive One important extension area is dynamic credentials. Static secret refs are not always enough for integrations that: - derive short-lived auth by calling login or refresh endpoints- need app-specific runtime headers- require token renewal logic The likely next auth-layer primitive is an auth provider or auth material resolver: - configured with secret refs and stable inputs- produces runtime auth material on demand- caches it with expiry metadata That is broader than sources and should be reusable by future source adapters, tool providers, and code bundles. ## Why auth is separated from recipes Recipes are shareable integration definitions.Credentials are private installation-specific state. That separation is important both for correctness and for shareability: - a recipe can be portable- a source binding can be local- credentials stay private This is the main reason auth is not modeled as part of the shareable recipe layer.