feat: allow extending account table #1041

New Issue

GiteaMirror · 2026-03-13T08:20:03-05:00

GiteaMirror commented

2026-03-13 08:20:03 -05:00

Originally created by @armannaj on GitHub (Apr 14, 2025).

Is this suited for github?

Yes, this is suited for github

Currently in linked account database table, there is field for "AccountId" which contains that social account numeric unique id (twitter ID, github ID). However, in most cases we need to show our users what username they linked with.

Describe the solution you'd like

Therefore I would like Accounts database table to have a new column for "AccountName" and every social oauth implementation fills this column with AccountName (twitter handle, google email, github username, etc.)

Describe alternatives you've considered

The alternative could be to have "additionalField" for "Account" object in auth.ts config so that we can extend core schema for Account object as well. Currently it is only possible for "user" and "session" objects.

However, if this approach is chosen, there should be a mapProfileToAccount hook as well, so that we can fill the value of this additional new field we just added.

Additional context

No response

Originally created by @armannaj on GitHub (Apr 14, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Currently in linked account database table, there is field for "AccountId" which contains that social account numeric unique id (twitter ID, github ID). However, in most cases we need to show our users what username they linked with. ### Describe the solution you'd like Therefore I would like Accounts database table to have a new column for "AccountName" and every social oauth implementation fills this column with AccountName (twitter handle, google email, github username, etc.) ### Describe alternatives you've considered The alternative could be to have "_additionalField_" for "Account" object in auth.ts config so that we can extend core schema for Account object as well. Currently it is only possible for "user" and "session" objects. However, if this approach is chosen, there should be a _mapProfileToAccount_ hook as well, so that we can fill the value of this additional new field we just added. ### Additional context _No response_

GiteaMirror added the enhancement label 2026-03-13 08:20:03 -05:00

GiteaMirror commented

2026-03-13 08:20:04 -05:00

@Kinfe123 commented on GitHub (Apr 14, 2025):

since they formed a link , username or handle is already there on the user side which you can still use additionalField feature on it ..so that you can rework on that - if you need additional pre and post processing regarding to that you can make sure to use hooks and get access to the account and user info with ctx.context.internalAdapter.*

@Kinfe123 commented on GitHub (Apr 14, 2025): since they formed a link , username or handle is already there on the user side which you can still use additionalField feature on it ..so that you can rework on that - if you need additional pre and post processing regarding to that you can make sure to use hooks and get access to the account and user info with `ctx.context.internalAdapter.*`

GiteaMirror commented

2026-03-13 08:20:04 -05:00

@elwin212 commented on GitHub (Apr 18, 2025):

Did you manage to solve this? I have the same question regarding account linking.
When using authClient.listAccounts, I’d also like to display each account’s name and email.
Since I’ve set allowDifferentEmails: true, a user can log in with different Google accounts, and showing their associated info would be helpful.

@elwin212 commented on GitHub (Apr 18, 2025): Did you manage to solve this? I have the same question regarding account linking. When using `authClient.listAccounts`, I’d also like to display each account’s name and email. Since I’ve set `allowDifferentEmails: true`, a user can log in with different Google accounts, and showing their associated info would be helpful.

GiteaMirror commented

2026-03-13 08:20:05 -05:00

@Bekacru commented on GitHub (May 6, 2025):

My recommendation is to store githubId and similar metadata in the user table in the mean time

@Bekacru commented on GitHub (May 6, 2025): My recommendation is to store `githubId` and similar metadata in the user table in the mean time

GiteaMirror commented

2026-03-13 08:20:06 -05:00

@dtc20h4802010137 commented on GitHub (May 14, 2025):

Did you manage to solve this? I have the same question regarding account linking. When using authClient.listAccounts, I’d also like to display each account’s name and email. Since I’ve set allowDifferentEmails: true, a user can log in with different Google accounts, and showing their associated info would be helpful.

Yeah, i want to display username or email of account that linked to user too. But cant find the way to do that, im trying to use access_token to get linked account info through provider api

@dtc20h4802010137 commented on GitHub (May 14, 2025): > Did you manage to solve this? I have the same question regarding account linking. When using `authClient.listAccounts`, I’d also like to display each account’s name and email. Since I’ve set `allowDifferentEmails: true`, a user can log in with different Google accounts, and showing their associated info would be helpful. Yeah, i want to display username or email of account that linked to user too. But cant find the way to do that, im trying to use access_token to get linked account info through provider api

GiteaMirror commented

2026-03-13 08:20:06 -05:00

@dosubot[bot] commented on GitHub (Aug 13, 2025):

Hi, @armannaj. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

You requested adding an "AccountName" column or schema extension to store usernames alongside AccountId in linked accounts.
I suggested using the existing additionalField feature and hooks to access and process account and user info for custom handling.
Other users expressed similar needs to display linked account names and emails, with some attempting to retrieve info via provider APIs.
A recommendation was made to temporarily store metadata like githubId in the user table.
The issue was resolved by encouraging custom solutions using existing features rather than adding a dedicated AccountName column.

Next Steps:

Please let me know if this issue is still relevant to the latest version of better-auth by commenting here.
Otherwise, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Aug 13, 2025): Hi, @armannaj. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You requested adding an "AccountName" column or schema extension to store usernames alongside AccountId in linked accounts. - I suggested using the existing additionalField feature and hooks to access and process account and user info for custom handling. - Other users expressed similar needs to display linked account names and emails, with some attempting to retrieve info via provider APIs. - A recommendation was made to temporarily store metadata like githubId in the user table. - The issue was resolved by encouraging custom solutions using existing features rather than adding a dedicated AccountName column. **Next Steps:** - Please let me know if this issue is still relevant to the latest version of better-auth by commenting here. - Otherwise, this issue will be automatically closed in 7 days. Thank you for your understanding and contribution!

GiteaMirror commented

2026-03-13 08:20:07 -05:00

@armannaj commented on GitHub (Aug 18, 2025):

Hi, @armannaj. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

You requested adding an "AccountName" column or schema extension to store usernames alongside AccountId in linked accounts.

I suggested using the existing additionalField feature and hooks to access and process account and user info for custom handling.

Other users expressed similar needs to display linked account names and emails, with some attempting to retrieve info via provider APIs.

A recommendation was made to temporarily store metadata like githubId in the user table.

The issue was resolved by encouraging custom solutions using existing features rather than adding a dedicated AccountName column.

Next Steps:

Please let me know if this issue is still relevant to the latest version of better-auth by commenting here.

Otherwise, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

hi there,

Yes, this issue still exists and would be good to solve it.

@armannaj commented on GitHub (Aug 18, 2025): > Hi, [@armannaj](https://github.com/armannaj). I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. > > **Issue Summary:** > > * You requested adding an "AccountName" column or schema extension to store usernames alongside AccountId in linked accounts. > * I suggested using the existing additionalField feature and hooks to access and process account and user info for custom handling. > * Other users expressed similar needs to display linked account names and emails, with some attempting to retrieve info via provider APIs. > * A recommendation was made to temporarily store metadata like githubId in the user table. > * The issue was resolved by encouraging custom solutions using existing features rather than adding a dedicated AccountName column. > > **Next Steps:** > > * Please let me know if this issue is still relevant to the latest version of better-auth by commenting here. > * Otherwise, this issue will be automatically closed in 7 days. > > Thank you for your understanding and contribution! hi there, Yes, this issue still exists and would be good to solve it.

GiteaMirror commented

2026-03-13 08:20:08 -05:00

@ghyath5 commented on GitHub (Oct 25, 2025):

I'm facing what seems to be the same issue with additionalFields not being returned, even when marked as returned: true.

Context

I'm using Better Auth with the Drizzle adapter and account linking enabled for Instagram.
The Instagram account linking works perfectly — the username is fetched from the Graph API and saved correctly in the database.
However, the username field is not included in the response from:

const accounts = await authClient.listAccounts();

Relevant Configuration

account: {
  additionalFields: {
    username: {
      type: "string",
      fieldName: "username",
      input: true,
      returned: true, // ✅ explicitly marked as returned
    },
  },
  accountLinking: {
    enabled: true,
    trustedProviders: ["instagram"],
    allowDifferentEmails: true,
  },
},

Observed Behavior

authClient.listAccounts() only returns the default fields:

id, providerId, accountId, scopes, createdAt, updatedAt

but does not include username, even though it’s stored in the database and marked as returned: true.

Expected Behavior

Any field defined in additionalFields (and flagged with returned: true) should also be included in the serialized response of authClient.listAccounts().

Notes

I confirmed the column exists in the database and is being populated correctly.
This appears to match the previously reported behavior where custom additionalFields are saved but not returned in client responses.

Is this the intended behavior, or is there a current limitation preventing custom fields from being serialized in listAccounts() responses?

@ghyath5 commented on GitHub (Oct 25, 2025): I'm facing what seems to be the same issue with `additionalFields` not being returned, even when marked as `returned: true`. #### Context I'm using **Better Auth** with the **Drizzle adapter** and **account linking enabled** for Instagram. The Instagram account linking works perfectly — the `username` is fetched from the Graph API and saved correctly in the database. However, the `username` field is **not included** in the response from: ```ts const accounts = await authClient.listAccounts(); ``` #### Relevant Configuration ```ts account: { additionalFields: { username: { type: "string", fieldName: "username", input: true, returned: true, // ✅ explicitly marked as returned }, }, accountLinking: { enabled: true, trustedProviders: ["instagram"], allowDifferentEmails: true, }, }, ``` #### Observed Behavior `authClient.listAccounts()` only returns the default fields: ``` id, providerId, accountId, scopes, createdAt, updatedAt ``` but **does not include `username`**, even though it’s stored in the database and marked as `returned: true`. #### Expected Behavior Any field defined in `additionalFields` (and flagged with `returned: true`) should also be included in the serialized response of `authClient.listAccounts()`. #### Notes - I confirmed the column exists in the database and is being populated correctly. - This appears to match the previously reported behavior where custom `additionalFields` are saved but not returned in client responses. Is this the intended behavior, or is there a current limitation preventing custom fields from being serialized in `listAccounts()` responses?

GiteaMirror commented

2026-03-13 08:20:08 -05:00

@cvienna commented on GitHub (Jan 1, 2026):

No Built-in Solution for Username/Email in Account Table

Better Auth doesn't natively support username or email fields in the Account table. Their source code literally says:

todo: we should use generics to extend this type with additional fields from plugins and options in the future.

Workaround

Create a temporary staging table:

export const pending_account = pgTable("pending_account", {
  id: text("id").primaryKey(),
  accountId: text("account_id").notNull(),
  username: text("username"),
});

Implementation

1. In getUserInfo (OAuth callback), stage the username:

getUserInfo: async (token) => {
  const response = await fetch(
    "https://www.googleapis.com/oauth2/v2/userinfo",
    { headers: { Authorization: `Bearer ${token.accessToken}` } }
  );
  const profile = await response.json();

  const result = await db
    .update(account)
    .set({ username: profile.username })
    .where(eq(account.accountId, profile.id));

  if (result.rowCount && result.rowCount > 0) {
    await db
      .delete(pending_account)
      .where(eq(pending_account.accountId, profile.id));
  } else {
    await db.insert(pending_account).values({
      id: generateId(32),
      accountId: profile.id,
      username: profile.username,
    });
  }

  return { user: { id: profile.id, name: profile.name, ... }, data: profile };
};

2. Use an after-hook to persist staged data:

hooks: {
  after: createAuthMiddleware(async (ctx) => {
    if (!ctx.path?.includes("/callback") || !ctx.headers) return;

    const userAccount = await auth.api.listUserAccounts({ headers: ctx.headers });
    const accountIds = userAccount.map((acc) => acc.accountId);

    const pendingAccounts = await db.query.pending_account.findMany({
      where: inArray(pending_account.accountId, accountIds),
    });

    if (pendingAccounts.length > 0) {
      await Promise.all(
        pendingAccounts.map((pending) =>
          db.update(account)
            .set({ username: pending.username })
            .where(eq(account.accountId, pending.accountId))
        )
      );

      await db.delete(pending_account)
        .where(inArray(pending_account.accountId, accountIds));
    }
  }),
}

Why This Works

OAuth callback triggers before account record exists. Staging table bridges the timing gap, then the hook syncs data once the account is created.

Simpler Alternative

Skip the after-hook and just put the update call directly in getUserInfo. Users need to re-authenticate once for the metadata to apply correctly, but it removes the staging complexity entirely.

@cvienna commented on GitHub (Jan 1, 2026): ## No Built-in Solution for Username/Email in Account Table Better Auth doesn't natively support username or email fields in the Account table. Their source code literally says: > todo: we should use generics to extend this type with additional fields from plugins and options in the future. ### Workaround **Create a temporary staging table:** ```typescript export const pending_account = pgTable("pending_account", { id: text("id").primaryKey(), accountId: text("account_id").notNull(), username: text("username"), }); ``` ### Implementation **1. In getUserInfo (OAuth callback), stage the username:** ```typescript getUserInfo: async (token) => { const response = await fetch( "https://www.googleapis.com/oauth2/v2/userinfo", { headers: { Authorization: `Bearer ${token.accessToken}` } } ); const profile = await response.json(); const result = await db .update(account) .set({ username: profile.username }) .where(eq(account.accountId, profile.id)); if (result.rowCount && result.rowCount > 0) { await db .delete(pending_account) .where(eq(pending_account.accountId, profile.id)); } else { await db.insert(pending_account).values({ id: generateId(32), accountId: profile.id, username: profile.username, }); } return { user: { id: profile.id, name: profile.name, ... }, data: profile }; }; ``` **2. Use an after-hook to persist staged data:** ```typescript hooks: { after: createAuthMiddleware(async (ctx) => { if (!ctx.path?.includes("/callback") || !ctx.headers) return; const userAccount = await auth.api.listUserAccounts({ headers: ctx.headers }); const accountIds = userAccount.map((acc) => acc.accountId); const pendingAccounts = await db.query.pending_account.findMany({ where: inArray(pending_account.accountId, accountIds), }); if (pendingAccounts.length > 0) { await Promise.all( pendingAccounts.map((pending) => db.update(account) .set({ username: pending.username }) .where(eq(account.accountId, pending.accountId)) ) ); await db.delete(pending_account) .where(inArray(pending_account.accountId, accountIds)); } }), } ``` ### Why This Works **OAuth callback triggers before account record exists. Staging table bridges the timing gap, then the hook syncs data once the account is created.** ### Simpler Alternative **Skip the after-hook and just put the update call directly in getUserInfo. Users need to re-authenticate once for the metadata to apply correctly, but it removes the staging complexity entirely.**

GiteaMirror commented

2026-03-13 08:20:08 -05:00

@afn commented on GitHub (Mar 11, 2026):

Here's a PR that adds an optional getAccountFields to the provider config to allow adding providerEmail (and any other relevant attributes) when creating the account: https://github.com/better-auth/better-auth/pull/8552

@afn commented on GitHub (Mar 11, 2026): Here's a PR that adds an optional `getAccountFields` to the provider config to allow adding `providerEmail` (and any other relevant attributes) when creating the account: https://github.com/better-auth/better-auth/pull/8552

GiteaMirror referenced this issue

2026-03-13 11:01:37 -05:00

[PR #1082] [MERGED] fix: add missing google auth uri params #3621

GiteaMirror referenced this issue

2026-04-13 03:41:01 -05:00

[GH-ISSUE #1041] Add support for setting hd "hostedDomain" parameter for Google OAuth #8564

GiteaMirror referenced this issue

2026-04-13 08:02:26 -05:00

[PR #1082] [MERGED] fix: add missing google auth uri params #11868

GiteaMirror referenced this issue

2026-04-15 15:13:17 -05:00

[GH-ISSUE #1041] Add support for setting hd "hostedDomain" parameter for Google OAuth #17195

GiteaMirror referenced this issue

2026-04-15 19:45:01 -05:00

[PR #1082] [MERGED] fix: add missing google auth uri params #20522

GiteaMirror referenced this issue

2026-04-17 16:12:06 -05:00

[GH-ISSUE #1041] Add support for setting hd "hostedDomain" parameter for Google OAuth #25887

GiteaMirror referenced this issue

2026-04-17 20:35:51 -05:00

[PR #1082] [MERGED] fix: add missing google auth uri params #29222

Sign in to join this conversation.

Branches Tags

2026-05-22/chore/adopt-agents-md

2026-05-22/refactor/string-case-utils

dependabot/npm_and_yarn/uuid-14.0.0

dependabot/npm_and_yarn/turbo-2.9.14

changeset-release/main

main

2026-05-14/fix/passkey-verify-error-and-claim

dependabot/npm_and_yarn/samlify-2.13.0

dependabot/npm_and_yarn/ws-8.20.1

changeset-release/next

dependabot/npm_and_yarn/demo/electron/demo-minor-patch-519ef7475f

dependabot/github_actions/github-actions-98f3470200

client-assertions-main

2026-05-15/ci/fix-sqlite-abi-mismatch

2026-05-15/fix/organization-team-add-cascade

2026-05-15/fix/parse-set-cookie-value-validation

2026-05-13/feat/captcha-wildcard-endpoints

2026-05-13/ci/stabilize-docker-startup

fix/i18n-before-hook-translation

fix/disable-migration-generate

2026-05-07/fix/admin-set-password-upsert

2026-05-10/fix/cookie-drain-order

2026-05-10/feat/hooks-finally

2026-05-09/fix/cookie-drain-order

2026-05-09/feat/hooks-finally

2026-05-08/feat/register-before-send

fix/stripe/subscription-data-merge

2026-05-01/chore/pnpm-v11-harden

chore/pnpm-v11

2026-04-29/feat/google-include-granted-scopes

2026-04-29/fix/oauth-account-scope-semantics

2026-04-27/fix/nextcookies-idempotent-writes

2026-04-26/fix/harden-proxy-host-validation

2026-04-26/refactor/stripe-callback-signature-cleanup

2026-04-26/fix/stripe-subscription-callback-timing

2026-04-11/fix/sveltekit-app-modules

feat/open-api-zod-contract

feat/oauth-provider-backchannel-logout-next

feat/oauth-idp-initiated-bounce

refactor/sign-in-challenges

2026-04-21/fix/oauth-rfc-input-validation

fix/release-notes-new-packages

fix/two-factor-identity-guard

fix/resource

feat/emailpassword-authorize

2026-04-12/security/dynamic-baseurl-proxy-trust-default

feat/oauth-provider-at-hash-v2

fix/release-grep-fallback

claude/address-review-comments-JhFLr

claude/slack-update-stripe-docs-consistency-8Sc0w

feat/async-auth

fix/two-factor-totp-verified-enrollment

feat/plugin-ui

codex/blog-1-6-release-post

2026-04-06/fix/type-any-guards

2026-04-05/chore/downgrade-better-call

2026-04-04/ci/skip-vercel-fork-prs

2026-03-28/ci/add-autofix-ci

chore/release-preview-script

himself65/2026/02/19/role

2026-03-24/fix/update-user-info-on-link

2026-03-20/docs/improve-website

2026-03-20/fix/anonymous-onlinkaccount-expo

2026-02-17/fix/anonymous-link-state

fix/8607-saml-inresponseto

fix/8549-scim-patch-noop

v1.4.x

refactor/migration-snapshot-tests

worktree-magic-link-additional-data

chore/migrate-build-to-rollup

worktree-fix-dynamic-baseurl-8447

2026-03-06/chore/public-api-check

fix/close-8156-regression-test

fix/secondary-storage-json-error-handling

himself65/verification-namespace

cursor/issue-8307-validation-79a3

himself65/2026/01/30/error-mdx

v1.4.x-staging

fix/email-otp-user

fix/restrict-full-organization-access-roles

himself65/2026/02/12/count

himself65/2026/02/04/define-plugin

2026-02-04/feat/add-pluralize

cursor/better-auth-js-integration-ec21

cursor/expo-state-mismatch-394c

2026-02-01/fix/org-update-role-sync-members

cursor/issue-7607-investigation-e146

cursor/email-generation-helper-0ff6

himself65/2026/01/21/avoid-spread-operator

himself65/2026/01/14/cli

claude/slack-add-docs-pr-NMvgO

claude/slack-add-advanced-useplural-WHKYL

feat/hooks-pos

feat/2fa-phone

feat/2fa

fix/rotation

fix/username-check

v1.3.x

refactor/organization

feat/multiple-client-ids-social-providers

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/better-auth#1041