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

[GH-ISSUE #6379] Next.js server components getAccessToken results to Account Not Found while client components succeed in stateless mode. (Cognito Provider) #10500

New Issue
Closed
opened 2026-04-13 06:41:20 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-13 06:41:20 -05:00
Owner
Copy Link

Originally created by @kenfdev on GitHub (Nov 28, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/6379

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Clone the reproduction repository: https://github.com/kenfdev/study-betterauth-nextjs
  2. Set up the environment with Cognito provider credentials
  3. Configure app/const.ts to use provider = 'cognito'
  4. Start the development server with npm run dev
  5. Navigate to /login and sign in with Cognito
  6. After successful authentication, navigate to /dashboard
  7. Observe that auth.api.getAccessToken() fails in the server component

Current vs. Expected behavior

Current behavior:

  • When signing in with Cognito, the better-auth.account_data cookie is not set in the browser
  • In server components, auth.api.getAccessToken({ providerId: 'cognito', headers }) fails because the account data is unavailable
  • In client components, authClient.getAccessToken({ providerId: 'cognito' }) succeeds (likely because it uses a different code path that doesn't rely on the cookie. not sure though)

Succeeding with github provider

Image

Server components failure with Cognito provider

Image

Expected behavior:

  • The better-auth.account_data cookie should be set consistently for all OAuth providers
  • getAccessToken() should work the same way in both server and client components

Root cause analysis:
Cognito returns 3 large JWT tokens (accessToken, refreshToken, idToken), which collectively exceed the browser's ~4KB cookie size limit. Example token sizes from my testing:

  • accessToken: ~870 chars
  • refreshToken: ~1560 chars
  • idToken: ~890 chars

This totals ~3320 chars just for the tokens, and after base64/encryption encoding with the other account fields (accountId, providerId, userId, etc.), the cookie value exceeds the 4KB limit
and silently fails to be set.

Google and GitHub providers work probably because their tokens are smaller and fit within the cookie limit.

What version of Better Auth are you using?

1.4.3

System info

{
  "system": {
    "platform": "linux",
    "arch": "x64",
    "version": "#1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025",
    "release": "6.6.87.2-microsoft-standard-WSL2",
    "cpuCount": 24,
    "cpuModel": "13th Gen Intel(R) Core(TM) i7-13700F",
    "totalMemory": "47.04 GB",
    "freeMemory": "33.16 GB"
  },
  "node": {
    "version": "v20.19.6",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "10.8.2"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "16.0.5"
    },
    {
      "name": "react",
      "version": "19.2.0"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    }
  ],
  "betterAuth": {
    "version": "^1.4.3",
    "config": {
      "logger": {
        "level": "debug",
        "disabled": false,
        "disableColors": false
      },
      "socialProviders": {
        "google": {},
        "github": {},
        "cognito": {}
      },
      "session": {
        "cookieCache": {
          "enabled": true,
          "maxAge": 604800,
          "strategy": "jwe",
          "refreshCache": true
        }
      },
      "account": {
        "updateAccountOnSignIn": true,
        "storeStateStrategy": "cookie",
        "storeAccountCookie": true
      },
      "plugins": []
    }
  }
}

Which area(s) are affected? (Select all that apply)

Backend, Client, Documentation

Auth config (if applicable)

import { betterAuth } from 'better-auth';

export const auth = betterAuth({
  logger: {
    level: 'debug',
    disabled: false,
    disableColors: false,
  },

  // Built-in social providers (commented out - using genericOAuth instead)
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID as string,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET as string,
    },
    github: {
      clientId: process.env.GITHUB_CLIENT_ID as string,
      clientSecret: process.env.GITHUB_CLIENT_SECRET as string,
    },
    cognito: {
      clientId: process.env.COGNITO_CLIENT_ID as string,
      clientSecret: process.env.COGNITO_CLIENT_SECRET as string,
      domain: process.env.COGNITO_DOMAIN as string, // e.g. "your-app.auth.us-east-1.amazoncognito.com"
      region: process.env.COGNITO_REGION as string, // e.g. "us-east-1"
      userPoolId: process.env.COGNITO_USERPOOL_ID as string,
    },
  },

  session: {
    cookieCache: {
      enabled: true,
      maxAge: 7 * 24 * 60 * 60, // 7 days cache duration
      strategy: 'jwe', // can be "jwt" or "compact"
      refreshCache: true, // Enable stateless refresh
    },
  },

  account: {
    updateAccountOnSignIn: true,
    storeStateStrategy: 'cookie',
    storeAccountCookie: true, // Store account data after OAuth flow in a cookie (useful for database-less flows)
  },

  plugins: [],
});

Additional context

Additional context

  • Configuration: Using storeAccountCookie: true in account config
  • Server component code (app/dashboard/page.tsx:21-26):
const tokenResponse = await auth.api.getAccessToken({
  body: { providerId: 'cognito' },
  headers: await headers(),
});
  • Client component code (app/dashboard/dashboard-client.tsx:18-24):
authClient.getAccessToken({ providerId: 'cognito' })
  .then((res) => {
    setAccessToken(res?.data?.accessToken ?? res?.accessToken ?? null);
  });
  • The client component call succeeds while the server component call fails, suggesting different underlying mechanisms
  • This is probably reproducible locally with any Cognito setup that returns all 3 tokens (though it may not depending on the token size)
Originally created by @kenfdev on GitHub (Nov 28, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/6379 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. Clone the reproduction repository: https://github.com/kenfdev/study-betterauth-nextjs 2. Set up the environment with Cognito provider credentials 3. Configure app/const.ts to use provider = 'cognito' 4. Start the development server with npm run dev 5. Navigate to /login and sign in with Cognito 6. After successful authentication, navigate to /dashboard 7. Observe that auth.api.getAccessToken() fails in the server component ### Current vs. Expected behavior Current behavior: - When signing in with Cognito, the better-auth.account_data cookie is not set in the browser - In server components, auth.api.getAccessToken({ providerId: 'cognito', headers }) fails because the account data is unavailable - In client components, authClient.getAccessToken({ providerId: 'cognito' }) succeeds (likely because it uses a different code path that doesn't rely on the cookie. not sure though) Succeeding with github provider <img width="982" height="1327" alt="Image" src="https://github.com/user-attachments/assets/791f737c-8f92-4136-a9dc-85fadf35ef81" /> Server components failure with Cognito provider <img width="917" height="921" alt="Image" src="https://github.com/user-attachments/assets/57aa4ad5-579a-4b6b-af3c-8c75c74ce13c" /> Expected behavior: - The better-auth.account_data cookie should be set consistently for all OAuth providers - getAccessToken() should work the same way in both server and client components Root cause analysis: Cognito returns 3 large JWT tokens (accessToken, refreshToken, idToken), which collectively exceed the browser's ~4KB cookie size limit. Example token sizes from my testing: - accessToken: ~870 chars - refreshToken: ~1560 chars - idToken: ~890 chars This totals ~3320 chars just for the tokens, and after base64/encryption encoding with the other account fields (accountId, providerId, userId, etc.), the cookie value exceeds the 4KB limit and silently fails to be set. Google and GitHub providers work probably because their tokens are smaller and fit within the cookie limit. ### What version of Better Auth are you using? 1.4.3 ### System info ```bash { "system": { "platform": "linux", "arch": "x64", "version": "#1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025", "release": "6.6.87.2-microsoft-standard-WSL2", "cpuCount": 24, "cpuModel": "13th Gen Intel(R) Core(TM) i7-13700F", "totalMemory": "47.04 GB", "freeMemory": "33.16 GB" }, "node": { "version": "v20.19.6", "env": "development" }, "packageManager": { "name": "npm", "version": "10.8.2" }, "frameworks": [ { "name": "next", "version": "16.0.5" }, { "name": "react", "version": "19.2.0" } ], "databases": [ { "name": "pg", "version": "^8.16.3" } ], "betterAuth": { "version": "^1.4.3", "config": { "logger": { "level": "debug", "disabled": false, "disableColors": false }, "socialProviders": { "google": {}, "github": {}, "cognito": {} }, "session": { "cookieCache": { "enabled": true, "maxAge": 604800, "strategy": "jwe", "refreshCache": true } }, "account": { "updateAccountOnSignIn": true, "storeStateStrategy": "cookie", "storeAccountCookie": true }, "plugins": [] } } } ``` ### Which area(s) are affected? (Select all that apply) Backend, Client, Documentation ### Auth config (if applicable) ```typescript import { betterAuth } from 'better-auth'; export const auth = betterAuth({ logger: { level: 'debug', disabled: false, disableColors: false, }, // Built-in social providers (commented out - using genericOAuth instead) socialProviders: { google: { clientId: process.env.GOOGLE_CLIENT_ID as string, clientSecret: process.env.GOOGLE_CLIENT_SECRET as string, }, github: { clientId: process.env.GITHUB_CLIENT_ID as string, clientSecret: process.env.GITHUB_CLIENT_SECRET as string, }, cognito: { clientId: process.env.COGNITO_CLIENT_ID as string, clientSecret: process.env.COGNITO_CLIENT_SECRET as string, domain: process.env.COGNITO_DOMAIN as string, // e.g. "your-app.auth.us-east-1.amazoncognito.com" region: process.env.COGNITO_REGION as string, // e.g. "us-east-1" userPoolId: process.env.COGNITO_USERPOOL_ID as string, }, }, session: { cookieCache: { enabled: true, maxAge: 7 * 24 * 60 * 60, // 7 days cache duration strategy: 'jwe', // can be "jwt" or "compact" refreshCache: true, // Enable stateless refresh }, }, account: { updateAccountOnSignIn: true, storeStateStrategy: 'cookie', storeAccountCookie: true, // Store account data after OAuth flow in a cookie (useful for database-less flows) }, plugins: [], }); ``` ### Additional context Additional context - Configuration: Using storeAccountCookie: true in account config - Server component code (app/dashboard/page.tsx:21-26): ```ts const tokenResponse = await auth.api.getAccessToken({ body: { providerId: 'cognito' }, headers: await headers(), }); ``` - Client component code (app/dashboard/dashboard-client.tsx:18-24): ```ts authClient.getAccessToken({ providerId: 'cognito' }) .then((res) => { setAccessToken(res?.data?.accessToken ?? res?.accessToken ?? null); }); ``` - The client component call succeeds while the server component call fails, suggesting different underlying mechanisms - This is probably reproducible locally with any Cognito setup that returns all 3 tokens (though it may not depending on the token size)
GiteaMirror added the lockedbug labels 2026-04-13 06:41:21 -05:00
GiteaMirror commented 2026-04-13 06:41:22 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Nov 28, 2025):

No reply.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3589111710 --> @better-auth-agent[bot] commented on GitHub (Nov 28, 2025): No reply. <!-- 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-13 06:41:23 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Nov 28, 2025):

Hi @kenfdev! I'm Dosu and I’m helping the better-auth team.

The root cause is that Cognito returns large tokens, which make the better-auth.account_data cookie exceed the browser's 4KB limit. When this happens, the cookie isn't set, so server components relying on it (like getAccessToken in RSCs) fail with "Account Not Found"—but client components may succeed because they use a different code path, often relying on in-memory or client-side state.

Better Auth v1.4.3 does not chunk or compress the account_data cookie—chunking is only implemented for session cookies, not account data. So, with large tokens (like Cognito's), the only options are to reduce the data stored in the cookie or avoid using cookies for account storage altogether. This is why GitHub and Google work (their tokens are smaller), but Cognito does not.

Recent versions of Better Auth (after v1.4.3) added support for filtering fields out of the cookie cache (using the returned: false config flag), and improved error handling so that exceeding the cookie size logs an error instead of throwing, but these do not solve the fundamental issue for large tokens unless you can exclude them from the cookie entirely [PR #5327].

Workarounds:

  • The most robust fix is to disable storeAccountCookie and use a database-backed adapter for account/session storage. This avoids the cookie size limit entirely and is the recommended approach for providers with large tokens [link-account.ts].
  • If you must stay stateless, you would need to filter or transform the account data before it is stored in the cookie, but as of v1.4.3, there is no built-in way to exclude built-in token fields from the account cookie.
  • Cookie chunking for account data is planned but not yet implemented as of your version.

Example config to switch to DB-backed storage:

export const auth = betterAuth({
  // ...other config
  account: {
    storeAccountCookie: false, // disables account_data cookie
    // ...other account config
  },
  // Add your database adapter here
  database: pgAdapter({ /* ... */ }),
});

If you upgrade to a newer Better Auth version, you can use the returned: false flag for custom fields, but this does not help with built-in token fields yet.

For now, the only reliable solution is to avoid storing large tokens in cookies by using a database adapter. This will make getAccessToken work in both server and client components, regardless of token size.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:3589143070 --> @dosubot[bot] commented on GitHub (Nov 28, 2025): <!-- Greeting --> Hi @kenfdev! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> The root cause is that Cognito returns large tokens, which make the `better-auth.account_data` cookie exceed the browser's 4KB limit. When this happens, the cookie isn't set, so server components relying on it (like `getAccessToken` in RSCs) fail with "Account Not Found"—but client components may succeed because they use a different code path, often relying on in-memory or client-side state. Better Auth v1.4.3 does not chunk or compress the `account_data` cookie—chunking is only implemented for session cookies, not account data. So, with large tokens (like Cognito's), the only options are to reduce the data stored in the cookie or avoid using cookies for account storage altogether. This is why GitHub and Google work (their tokens are smaller), but Cognito does not. Recent versions of Better Auth (after v1.4.3) added support for filtering fields out of the cookie cache (using the `returned: false` config flag), and improved error handling so that exceeding the cookie size logs an error instead of throwing, but these do not solve the fundamental issue for large tokens unless you can exclude them from the cookie entirely [[PR #5327](https://github.com/better-auth/better-auth/pull/5327)]. **Workarounds:** - The most robust fix is to disable `storeAccountCookie` and use a database-backed adapter for account/session storage. This avoids the cookie size limit entirely and is the recommended approach for providers with large tokens [[link-account.ts](https://github.com/better-auth/better-auth/blob/8248dad72bac5685d1b9e7c7dd58dd734914b46e/packages/better-auth/src/oauth2/link-account.ts#L97-L124)]. - If you must stay stateless, you would need to filter or transform the account data before it is stored in the cookie, but as of v1.4.3, there is no built-in way to exclude built-in token fields from the account cookie. - Cookie chunking for account data is planned but not yet implemented as of your version. **Example config to switch to DB-backed storage:** ```ts export const auth = betterAuth({ // ...other config account: { storeAccountCookie: false, // disables account_data cookie // ...other account config }, // Add your database adapter here database: pgAdapter({ /* ... */ }), }); ``` If you upgrade to a newer Better Auth version, you can use the `returned: false` flag for custom fields, but this does not help with built-in token fields yet. For now, the only reliable solution is to avoid storing large tokens in cookies by using a database adapter. This will make `getAccessToken` work in both server and client components, regardless of token size. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/df626f68-ded4-4b76-bfed-bbb4fbf33f28?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20root%20cause%20is%20that%20Cognito%20returns%20large%20tokens%2C%20which%20make%20the%20%60better-auth.account_data%60%20cookie%20exceed%20the%20browser%27s%204KB%20limit.%20When%20this%20happens%2C%20the%20cookie%20isn%27t%20set%2C%20so%20server%20components%20relying%20on%20it%20%28like%20%60getAccessToken%60%20in%20RSCs%29%20fail%20with%20%22Account%20Not%20Found%22%E2%80%94but%20client%20components%20may%20succeed%20because%20they%20use%20a%20different%20code%20path%2C%20often%20relying%20on%20in-memory%20or%20client-side%20state.%0A%0ABetter%20Auth%20v1.4.3%20does%20not%20chunk%20or%20compress%20the%20%60account_data%60%20cookie%E2%80%94chunking%20is%20only%20implemented%20for%20session%20cookies%2C%20not%20account%20data.%20So%2C%20with%20large%20tokens%20%28like%20Cognito%27s%29%2C%20the%20only%20options%20are%20to%20reduce%20the%20data%20stored%20in%20the%20cookie%20or%20avoid%20using%20cookies%20for%20account%20storage%20altogether.%20This%20is%20why%20GitHub%20and%20Google%20work%20%28their%20tokens%20are%20smaller%29%2C%20but%20Cognito%20does%20not.%0A%0ARecent%20versions%20of%20Better%20Auth%20%28after%20v1.4.3%29%20added%20support%20for%20filtering%20fields%20out%20of%20the%20cookie%20cache%20%28using%20the%20%60returned%3A%20false%60%20config%20flag%29%2C%20and%20improved%20error%20handling%20so%20that%20exceeding%20the%20cookie%20size%20logs%20an%20error%20instead%20of%20throwing%2C%20but%20these%20do%20not%20solve%20the%20fundamental%20issue%20for%20large%20tokens%20unless%20you%20can%20exclude%20them%20from%20the%20cookie%20entirely%20%5B%5BPR%20%235327%5D%28https%3A//github.com/better-auth/better-auth/pull/5327%29%5D.%0A%0A%2A%2AWorkarounds%3A%2A%2A%0A-%20The%20most%20robust%20fix%20is%20to%20disable%20%60storeAccountCookie%60%20and%20use%20a%20database-backed%20adapter%20for%20account/session%20storage.%20This%20avoids%20the%20cookie%20size%20limit%20entirely%20and%20is%20the%20recommended%20approach%20for%20providers%20with%20large%20tokens%20%5B%5Blink-account.ts%5D%28https%3A//github.com/better-auth/better-auth/blob/8248dad72bac5685d1b9e7c7dd58dd734914b46e/packages/better-auth/src/oauth2/link-account.ts%23L97-L124%29%5D.%0A-%20If%20you%20must%20stay%20stateless%2C%20you%20would%20need%20to%20filter%20or%20transform%20the%20account%20data%20before%20it%20is%20stored%20in%20the%20cookie%2C%20but%20as%20of%20v1.4.3%2C%20there%20is%20no%20built-in%20way%20to%20exclude%20built-in%20token%20fields%20from%20the%20account%20cookie.%0A-%20Cookie%20chunking%20for%20account%20data%20is%20planned%20but%20not%20yet%20implemented%20as%20of%20your%20version.%0A%0A%2A%2AExample%20config%20to%20switch%20to%20DB-backed%20storage%3A%2A%2A%0A%60%60%60ts%0Aexport%20const%20auth%20%3D%20betterAuth%28%7B%0A%20%20//%20...other%20config%0A%20%20account%3A%20%7B%0A%20%20%20%20storeAccountCookie%3A%20false%2C%20//%20disables%20account_data%20cookie%0A%20%20%20%20//%20...other%20account%20config%0A%20%20%7D%2C%0A%20%20//%20Add%20your%20database%20adapter%20here%0A%20%20database%3A%20pgAdapter%28%7B%20/%2A%20...%20%2A/%20%7D%29%2C%0A%7D%29%3B%0A%60%60%60%0A%0AIf%20you%20upgrade%20to%20a%20newer%20Better%20Auth%20version%2C%20you%20can%20use%20the%20%60returned%3A%20false%60%20flag%20for%20custom%20fields%2C%20but%20this%20does%20not%20help%20with%20built-in%20token%20fields%20yet.%0A%0AFor%20now%2C%20the%20only%20reliable%20solution%20is%20to%20avoid%20storing%20large%20tokens%20in%20cookies%20by%20using%20a%20database%20adapter.%20This%20will%20make%20%60getAccessToken%60%20work%20in%20both%20server%20and%20client%20components%2C%20regardless%20of%20token%20size.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/6379)
GiteaMirror commented 2026-04-13 06:41:23 -05:00
Author
Owner
Copy Link

@nicosh commented on GitHub (Nov 28, 2025):

Same issue with genericOAuth and keycloak

<!-- gh-comment-id:3589462693 --> @nicosh commented on GitHub (Nov 28, 2025): Same issue with `genericOAuth` and keycloak
GiteaMirror commented 2026-04-13 06:41:24 -05:00
Author
Owner
Copy Link

@dszmaj7 commented on GitHub (Nov 28, 2025):

Same issue with microsoft provider.

<!-- gh-comment-id:3589877488 --> @dszmaj7 commented on GitHub (Nov 28, 2025): Same issue with `microsoft` provider.
GiteaMirror commented 2026-04-13 06:41:26 -05:00
Author
Owner
Copy Link

@kenfdev commented on GitHub (Nov 30, 2025):

@Bekacru @jslno
I've confirmed #6393 temporarily fixes the bloated cookie issue by chunking it.

Image

However, after I sign out and sign in again, I still get Account Not Found when executing getAccessToken.

Error [APIError]: Account not found
    at async DashboardPage (app/dashboard/page.tsx:21:27)
  19 |   let githubToken = null;
  20 |   try {
> 21 |     const tokenResponse = await auth.api.getAccessToken({
     |                           ^
  22 |       body: {
  23 |         providerId: provider,
  24 |       }, {
  status: 'BAD_REQUEST',
  body: [Object],
  headers: {},
  statusCode: 400
}

After I reset the app, it works again. I guess this is related to #6252 .

Setting updateAccountOnSignIn to false as dosubot suggests, does fix the issue. Not sure if this is intended or not though.

Thanks for all the support.

<!-- gh-comment-id:3593817804 --> @kenfdev commented on GitHub (Nov 30, 2025): @Bekacru @jslno I've confirmed #6393 temporarily fixes the bloated cookie issue by chunking it. <img width="594" height="151" alt="Image" src="https://github.com/user-attachments/assets/556cdace-0e0b-4050-bc4a-6fcc5bd997aa" /> However, after I sign out and sign in again, I still get `Account Not Found` when executing `getAccessToken`. ```sh Error [APIError]: Account not found at async DashboardPage (app/dashboard/page.tsx:21:27) 19 | let githubToken = null; 20 | try { > 21 | const tokenResponse = await auth.api.getAccessToken({ | ^ 22 | body: { 23 | providerId: provider, 24 | }, { status: 'BAD_REQUEST', body: [Object], headers: {}, statusCode: 400 } ``` After I reset the app, it works again. I guess this is related to #6252 . Setting `updateAccountOnSignIn` to `false` as `dosubot` suggests, does fix the issue. Not sure if this is intended or not though. Thanks for all the support.
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 bug locked
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#10500
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?