service accounts: Phase 1 — backend CRUD and API key token exchange#2943
Draft
GregorShear wants to merge 1 commit into
Draft
service accounts: Phase 1 — backend CRUD and API key token exchange#2943GregorShear wants to merge 1 commit into
GregorShear wants to merge 1 commit into
Conversation
GregorShear
force-pushed
the
greg/service-accounts-phase1
branch
from
8a5b938 to
044861d
Compare
Adds service account lifecycle management via GraphQL and API key authentication
via a new REST token exchange endpoint.
Data model:
- internal.service_accounts: identities keyed by auth.users.id, with owning
prefix, capability, and disabled state
- internal.api_keys: long-lived credentials (bcrypt-hashed) exchanged for
short-lived JWTs, with fixed expiry (no sliding window)
GraphQL mutations (all require admin on the service account's prefix):
- createServiceAccount: creates auth.users + service_accounts + user_grants rows
- disableServiceAccount: revokes all API keys and grants, sets disabled_at
- enableServiceAccount: clears disabled_at, restores the user_grants row
- createApiKey: mints a flow_sa_-prefixed secret (returned once, stored as hash)
- revokeApiKey: deletes the API key row
GraphQL query:
- serviceAccounts: paginated list scoped to caller's admin prefixes, includes
nested apiKeys (without secrets)
Token exchange:
- POST /api/v1/auth/token accepts {"grant_type": "api_key", "api_key": "..."}
or {"grant_type": "refresh_token", "refresh_token_id": "...", "secret": "..."}.
The API key path validates credentials and signs JWTs in the Rust application
layer. The refresh token path delegates to the existing generate_access_token
SQL function. The existing function is unchanged.
Phase 1 of the service accounts plan (#2857).
GregorShear
force-pushed
the
greg/service-accounts-phase1
branch
from
044861d to
899d324
Compare
GregorShear
commented
May 20, 2026
|
|
||
| .claude/* | ||
| !.claude/skills/ | ||
| mise.local.toml |
Contributor
Author
There was a problem hiding this comment.
not related to this PR but helping me not commit a file related to a parallel workstream...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
internal.service_accountsandinternal.api_keystables for non-human identities that authenticate via API keys and are authorized through the existinguser_grants/role_grantssystemcreateServiceAccount,disableServiceAccount,enableServiceAccount,createApiKey,revokeApiKey) and a paginatedserviceAccountsquery, all gated on admin capability of the service account's prefixgenerate_access_tokento accept aflow_sa_-prefixed API key alongside the existing refresh token path — the two input shapes are mutually exclusive, and existing callers are unaffectedPhase 1 of the service accounts plan. Unlocks Phases 2–7 (management UI, OIDC, flowctl integration).
Key design decisions
auth.usersrows. All existing RLS policies, PostgREST authorization,user_roles()resolution, androle_grantstraversal work unchanged. This avoids putting the PostgREST→GraphQL migration on the critical path.user_grantsrow per service account. Disabling deletes the grant and all API keys; re-enabling restores the grant from the service account's stored prefix/capability.flow_sa_prefix routes server-side lookups tointernal.api_keysand prevents collisions with base64-encoded refresh tokens.generate_access_tokendrops the old 2-arg signature and replaces it with a 3-arg version (all with defaults). Existing positional and named callers continue to work unchanged.Test plan
sqlx prepare— new queries need to be added to the offline cache in CItest_service_account_lifecyclecovers: