feat(api): allow owners and admins to create an API key for another member - #4925
Open
airflow-ommax wants to merge 1 commit into
Open
feat(api): allow owners and admins to create an API key for another member#4925airflow-ommax wants to merge 1 commit into
airflow-ommax wants to merge 1 commit into
Conversation
…ember createApiKey already forwards a userId to better-auth, but the tRPC route hardcoded the caller, so a key could only ever be minted for the calling session's user. Automation that provisions users (SSO/SCIM-style onboarding) therefore had no way to bootstrap a per-user key, and the only workaround was sharing one admin key across everyone, which loses attribution and per-user revocation. Accept an optional userId. Minting for someone else requires the caller to be an organization owner or admin, requires metadata.organizationId, and verifies the target is a member of that organization. Omitting userId keeps the previous behaviour exactly, so this is backwards compatible. The audit entry records that the key was created on behalf of another user. The authorization decision is a pure helper in lib/api-keys.ts with unit tests, next to the existing api-key name validation.
dosubot
Bot
added
size:M
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.
Problem
user.createApiKeycan only ever mint a key for the calling session's user: the service function already forwards auserIdto better-auth, but the tRPC route hardcodesctx.user.id.That leaves automation with no way to bootstrap a per-user key. Anything that provisions users (SSO/SCIM-style onboarding, an internal developer platform handing each engineer their own credential) has to fall back to sharing a single admin key across everyone, which loses per-user attribution and per-user revocation, the two properties API keys exist for.
Change
createApiKeyaccepts an optionaluserId.Minting for someone else is gated:
metadata.organizationIdis required in that caseOmitting
userIdkeeps the existing behaviour byte for byte, so this is backwards compatible and the UI is unchanged. The audit entry records when a key was created on behalf of another user.Security
A key minted this way carries the target user's permissions, not the caller's, so the authorization decision is deliberately kept in one pure place (
canCreateApiKeyForAnotherUserinlib/api-keys.ts, next to the existing api-key name validation) rather than inlined. It refuses an absent or empty role instead of defaulting to allowed, and it is case-sensitive.Tests
Unit tests for the guard added alongside the existing
apiKeyNameSchematests in__test__/api/api-key-name.test.ts(owner/admin allowed, member refused, absent/empty role refused).Note: I could not run the full suite locally without a complete monorepo install, so CI is the check for the rest.
Backwards compatibility
No migration, no schema change, no UI change. Existing callers that omit
userIdare unaffected.