github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 23:52:05 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #7333] [Feature Request] Allow authenticated users to set permissions when creating their own API keys #19418

New Issue
Open
opened 2026-04-15 18:29:18 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-15 18:29:18 -05:00
Owner
Copy Link

Originally created by @grmkris on GitHub (Jan 13, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7333

Problem

Currently, authClient.apiKey.create() rejects the permissions field with error:

THE_PROPERTY_YOU'RE_TRYING_TO_SET_CAN_ONLY_BE_SET_FROM_THE_SERVER_AUTH_INSTANCE_ONLY

This forces developers to create server-side wrapper endpoints just to call auth.api.createApiKey() with permissions.

Use Case

A logged-in user should be able to create their own API keys with custom permissions. For example:

  • User wants a "read-only" key for monitoring dashboards
  • User wants a "full access" key for CI/CD deployments
  • User wants granular permissions for different integrations

Current Workaround

Developers must:

  1. Create a server-side RPC endpoint
  2. Validate the user's session
  3. Call auth.api.createApiKey() with permissions
  4. Return the key to the client

This adds unnecessary boilerplate when the user is already authenticated.

Proposed Solution

Allow permissions in client-side apiKey.create() when the user is authenticated, with optional server-side validation:

apiKey({
  permissions: {
    allowClientPermissions: true, // NEW: Allow authenticated users to set permissions
    // Optional: Limit what permissions users can grant themselves
    maxPermissions: {
      files: ["read", "write"],
      users: ["read"],
    },
  },
})

Security Consideration

The concern is users granting themselves elevated permissions. But:

  1. Users can only create keys for their own account
  2. Server can define maxPermissions to cap what's allowed
  3. This is no different than the user doing actions directly via session auth

Reproducible Example

// Server config
const auth = betterAuth({
  plugins: [
    apiKey({
      permissions: {
        defaultPermissions: { files: ["read"] },
      },
    }),
  ],
});

// Client (logged in user)
const result = await authClient.apiKey.create({
  name: "My Key",
  permissions: { files: ["read", "write"] }, // ❌ FAILS
});
// Error: "can only be set from server auth instance"

Related

  • Issue #6217 documented this as "intentional" but didn't provide justification for blocking authenticated users
  • PR #6229 updated docs but didn't address the UX problem
Originally created by @grmkris on GitHub (Jan 13, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7333 ## Problem Currently, `authClient.apiKey.create()` rejects the `permissions` field with error: ``` THE_PROPERTY_YOU'RE_TRYING_TO_SET_CAN_ONLY_BE_SET_FROM_THE_SERVER_AUTH_INSTANCE_ONLY ``` This forces developers to create server-side wrapper endpoints just to call `auth.api.createApiKey()` with permissions. ## Use Case A logged-in user should be able to create their own API keys with custom permissions. For example: - User wants a "read-only" key for monitoring dashboards - User wants a "full access" key for CI/CD deployments - User wants granular permissions for different integrations ## Current Workaround Developers must: 1. Create a server-side RPC endpoint 2. Validate the user's session 3. Call `auth.api.createApiKey()` with permissions 4. Return the key to the client This adds unnecessary boilerplate when the user is already authenticated. ## Proposed Solution Allow `permissions` in client-side `apiKey.create()` **when the user is authenticated**, with optional server-side validation: ```ts apiKey({ permissions: { allowClientPermissions: true, // NEW: Allow authenticated users to set permissions // Optional: Limit what permissions users can grant themselves maxPermissions: { files: ["read", "write"], users: ["read"], }, }, }) ``` ## Security Consideration The concern is users granting themselves elevated permissions. But: 1. Users can only create keys for **their own account** 2. Server can define `maxPermissions` to cap what's allowed 3. This is no different than the user doing actions directly via session auth ## Reproducible Example ```ts // Server config const auth = betterAuth({ plugins: [ apiKey({ permissions: { defaultPermissions: { files: ["read"] }, }, }), ], }); // Client (logged in user) const result = await authClient.apiKey.create({ name: "My Key", permissions: { files: ["read", "write"] }, // ❌ FAILS }); // Error: "can only be set from server auth instance" ``` ## Related - Issue #6217 documented this as "intentional" but didn't provide justification for blocking authenticated users - PR #6229 updated docs but didn't address the UX problem
GiteaMirror added the security label 2026-04-15 18:29:18 -05:00
GiteaMirror commented 2026-04-15 18:29:19 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Jan 13, 2026):

I see you've raised a feature request about allowing authenticated users to set permissions when creating their own API keys in Better Auth. Currently, as you noted, the authClient.apiKey.create() method does not accept permissions from the client side, which leads to the need for additional server-side handling.

From what you've described, the ability to allow users to create API keys with custom permissions could enhance user experience significantly by reducing boilerplate code when users are already authenticated. Your example demonstrates the issue well, highlighting the constraint around permissions.

There may be concerns to address about security and ensuring that users do not set themselves elevated permissions; however, your suggestions for server-side validations and defining maximum permissions seem reasonable.

For next steps, I would recommend opening a discussion within the Better Auth community or tagging the team members, Beka and Max, as they can provide more insights or respond to the feature request. Feel free to tag @bekacru or @ping__ for further guidance.

What specific use cases do you imagine this feature would help with in your application?

If you need more help, tag @better-auth-agent in a comment so I can respond.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3745269061 --> @better-auth-agent[bot] commented on GitHub (Jan 13, 2026): I see you've raised a feature request about allowing authenticated users to set permissions when creating their own API keys in Better Auth. Currently, as you noted, the `authClient.apiKey.create()` method does not accept `permissions` from the client side, which leads to the need for additional server-side handling. From what you've described, the ability to allow users to create API keys with custom permissions could enhance user experience significantly by reducing boilerplate code when users are already authenticated. Your example demonstrates the issue well, highlighting the constraint around permissions. There may be concerns to address about security and ensuring that users do not set themselves elevated permissions; however, your suggestions for server-side validations and defining maximum permissions seem reasonable. For next steps, I would recommend opening a discussion within the Better Auth community or tagging the team members, Beka and Max, as they can provide more insights or respond to the feature request. Feel free to tag @bekacru or @ping__ for further guidance. What specific use cases do you imagine this feature would help with in your application? _If you need more help, tag @better-auth-agent in a comment so I can respond._ <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 18:29:20 -05:00
Author
Owner
Copy Link

@ChetanReddyC commented on GitHub (Jan 13, 2026):

Hey @Bekacru and @ping-maxwell

Tagging you both for guidance on this feature request. The idea is to allow authenticated users to set scoped permissions when creating their own API keys via authClient.apiKey.create().

This wouldn’t be about privilege escalation server-side checks could ensure users can only create keys within an allowed/max permission set. The goal is mainly to reduce extra server boilerplate and improve DX for already-authenticated users.

Would love to know if this aligns with Better Auth’s direction or if there are security/design concerns I should account for before moving forward. Thanks!

<!-- gh-comment-id:3745445862 --> @ChetanReddyC commented on GitHub (Jan 13, 2026): Hey @Bekacru and @ping-maxwell Tagging you both for guidance on this feature request. The idea is to allow authenticated users to set scoped permissions when creating their own API keys via authClient.apiKey.create(). This wouldn’t be about privilege escalation server-side checks could ensure users can only create keys within an allowed/max permission set. The goal is mainly to reduce extra server boilerplate and improve DX for already-authenticated users. Would love to know if this aligns with Better Auth’s direction or if there are security/design concerns I should account for before moving forward. Thanks!
GiteaMirror commented 2026-04-15 18:29:21 -05:00
Author
Owner
Copy Link

@grmkris commented on GitHub (Jan 14, 2026):

life is good

<!-- gh-comment-id:3751684470 --> @grmkris commented on GitHub (Jan 14, 2026): life is good
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#19418
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?