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

Allow excluding user fields from cookie cache to prevent oversized cookies #2139

New Issue
Open
opened 2026-03-13 09:29:46 -05:00 by GiteaMirror · 15 comments
GiteaMirror commented 2026-03-13 09:29:46 -05:00
Owner
Copy Link

Originally created by @gottfrois on GitHub (Oct 17, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Configure BetterAuth with Microsoft OAuth provider and cookie cache enabled:
  export const auth = betterAuth({
    session: {
      cookieCache: {
        enabled: true,
        maxAge: 300
      }
    },
    socialProviders: {
      microsoft: {
        clientId: env.MICROSOFT_CLIENT_ID,
        clientSecret: env.MICROSOFT_CLIENT_SECRET,
        tenantId: env.MICROSOFT_TENANT_ID,
      }
    }
  });
  1. Sign in using Microsoft OAuth
  2. Microsoft returns a base64-encoded profile picture in the user.image field (often 10-50KB+)
  3. BetterAuth attempts to cache the entire user object (including the large image) in the session cookie
  4. The cookie exceeds the 4KB browser limit, causing a 500 error on GET /api/auth/callback/microsoft

Current vs. Expected behavior

Current Behavior

When session.cookieCache.enabled is true, the entire user object (including the image field) is serialized into the cookie. There is no way to exclude specific core user fields from being cached. The returned: false property in additionalFields only works for custom fields, not for built-in fields like user.image.

Expected Behavior

I should be able to configure which user fields are excluded from cookie cache to prevent oversized cookies.

For example:

  session: {
    cookieCache: {
      enabled: true,
      maxAge: 300,
      excludeUserFields: ["image"] // Don't cache these user fields in cookies
    }
  }

This would allow cookie caching for performance benefits while avoiding the cookie size limit issue with large fields like profile images.

Current Workaround

The only workaround is to disable cookie cache entirely with enabled: false, which eliminates the performance benefits of cookie caching.

What version of Better Auth are you using?

1.3.11

System info

npx @better-auth/cli info --json
error: unknown command 'info'

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

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";

export const auth = betterAuth({
  appName: "Lia",
  secret: env.BETTER_AUTH_SECRET,
  session: {
    cookieCache: {
      // Currently disabled due to cookie size issues with Microsoft SSO
      // profile pictures encoded in base64 being too large
      enabled: false,
    },
  },
  database: drizzleAdapter(db, {
    provider: "pg",
    schema: { /* ... */ },
  }),
  socialProviders: {
    microsoft: {
      prompt: "select_account",
      clientId: env.MICROSOFT_CLIENT_ID,
      clientSecret: env.MICROSOFT_CLIENT_SECRET,
      tenantId: env.MICROSOFT_TENANT_ID,
    },
  },
});

Additional context

  • This issue specifically affects OAuth providers that return large base64-encoded profile images (Microsoft, potentially others)
  • The issue occurs both locally and in production
  • Browser cookie size limit is typically 4KB, but the base64-encoded images can be 10-50KB+
  • Cookie caching is a valuable performance optimization, but it's unusable when user objects contain large fields
Originally created by @gottfrois on GitHub (Oct 17, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. Configure BetterAuth with Microsoft OAuth provider and cookie cache enabled: ```ts export const auth = betterAuth({ session: { cookieCache: { enabled: true, maxAge: 300 } }, socialProviders: { microsoft: { clientId: env.MICROSOFT_CLIENT_ID, clientSecret: env.MICROSOFT_CLIENT_SECRET, tenantId: env.MICROSOFT_TENANT_ID, } } }); ``` 2. Sign in using Microsoft OAuth 3. Microsoft returns a base64-encoded profile picture in the user.image field (often 10-50KB+) 4. BetterAuth attempts to cache the entire user object (including the large image) in the session cookie 5. The cookie exceeds the 4KB browser limit, causing a 500 error on GET /api/auth/callback/microsoft ### Current vs. Expected behavior ### Current Behavior When `session.cookieCache.enabled` is `true`, the entire user object (including the image field) is serialized into the cookie. There is no way to exclude specific core user fields from being cached. The `returned: false` property in `additionalFields` only works for custom fields, not for built-in fields like `user.image`. ### Expected Behavior I should be able to configure which user fields are excluded from cookie cache to prevent oversized cookies. For example: ```ts session: { cookieCache: { enabled: true, maxAge: 300, excludeUserFields: ["image"] // Don't cache these user fields in cookies } } ``` This would allow cookie caching for performance benefits while avoiding the cookie size limit issue with large fields like profile images. ### Current Workaround The only workaround is to disable cookie cache entirely with `enabled: false`, which eliminates the performance benefits of cookie caching. ### What version of Better Auth are you using? 1.3.11 ### System info ```bash npx @better-auth/cli info --json error: unknown command 'info' ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth"; import { drizzleAdapter } from "better-auth/adapters/drizzle"; export const auth = betterAuth({ appName: "Lia", secret: env.BETTER_AUTH_SECRET, session: { cookieCache: { // Currently disabled due to cookie size issues with Microsoft SSO // profile pictures encoded in base64 being too large enabled: false, }, }, database: drizzleAdapter(db, { provider: "pg", schema: { /* ... */ }, }), socialProviders: { microsoft: { prompt: "select_account", clientId: env.MICROSOFT_CLIENT_ID, clientSecret: env.MICROSOFT_CLIENT_SECRET, tenantId: env.MICROSOFT_TENANT_ID, }, }, }); ``` ### Additional context - This issue specifically affects OAuth providers that return large base64-encoded profile images (Microsoft, potentially others) - The issue occurs both locally and in production - Browser cookie size limit is typically 4KB, but the base64-encoded images can be 10-50KB+ - Cookie caching is a valuable performance optimization, but it's unusable when user objects contain large fields
GiteaMirror added the enhancement label 2026-03-13 09:29:46 -05:00
GiteaMirror commented 2026-03-13 09:29:48 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Oct 17, 2025):

BetterAuth does not currently support excluding built-in user fields (like image) from cookie cache serialization via a config option such as excludeUserFields. The only filtering available is for custom fields defined in additionalFields using the returned: false property, which does not apply to built-in fields like user.image source. If the session data exceeds the browser cookie size limit, BetterAuth will skip setting the cookie and log a warning, but there is no built-in way to exclude large built-in fields from the cache source.

The recommended workaround is to filter or transform large fields (such as base64-encoded images) at the adapter or integration layer before they reach the cookie cache. Until field exclusion or cookie chunking is supported, disabling cookie cache is the only way to avoid this issue if you can't reduce the session data size source.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 17, 2025): <!-- Answer --> BetterAuth does not currently support excluding built-in user fields (like `image`) from cookie cache serialization via a config option such as `excludeUserFields`. The only filtering available is for custom fields defined in `additionalFields` using the `returned: false` property, which does not apply to built-in fields like `user.image` [source](https://github.com/better-auth/better-auth/issues/5293#issuecomment-3399919580). If the session data exceeds the browser cookie size limit, BetterAuth will skip setting the cookie and log a warning, but there is no built-in way to exclude large built-in fields from the cache [source](https://github.com/better-auth/better-auth/issues/4697). The recommended workaround is to filter or transform large fields (such as base64-encoded images) at the adapter or integration layer before they reach the cookie cache. Until field exclusion or cookie chunking is supported, disabling cookie cache is the only way to avoid this issue if you can't reduce the session data size [source](https://github.com/better-auth/better-auth/discussions/5066#discussioncomment-14582432). <!-- 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/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/0a7ec1bb-5e91-4104-8f42-bdefa041bc1e?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&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/5378)
GiteaMirror commented 2026-03-13 09:29:48 -05:00
Author
Owner
Copy Link

@Blackmamoth commented on GitHub (Oct 18, 2025):

Hey @gottfrois , are you working on this? If not, I'd like to work on it and open a PR.

Also wanted to ask, would it make sense to have excludeSessionFields as well, or is excludeUserFields sufficient for most use cases?

@Blackmamoth commented on GitHub (Oct 18, 2025): Hey @gottfrois , are you working on this? If not, I'd like to work on it and open a PR. Also wanted to ask, would it make sense to have `excludeSessionFields` as well, or is `excludeUserFields` sufficient for most use cases?
GiteaMirror commented 2026-03-13 09:29:49 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Oct 19, 2025):

I think our current goal is to support cookie chunking, this way we can support any size.

@ping-maxwell commented on GitHub (Oct 19, 2025): I think our current goal is to support cookie chunking, this way we can support any size.
GiteaMirror commented 2026-03-13 09:29:50 -05:00
Author
Owner
Copy Link

@Blackmamoth commented on GitHub (Oct 19, 2025):

That makes total sense, cookie chunking sounds like a way better approach

Should I close my PR or is this something I could take on? Totally get it if you want to handle it internally though. Either way, happy to help! @ping-maxwell

@Blackmamoth commented on GitHub (Oct 19, 2025): That makes total sense, cookie chunking sounds like a way better approach Should I close my PR or is this something I could take on? Totally get it if you want to handle it internally though. Either way, happy to help! @ping-maxwell
GiteaMirror commented 2026-03-13 09:29:51 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Oct 19, 2025):

Hmm it's possible this is okay to support but I feel like there are possibly a lot of nuances that aren't considered.
Maybe for now hold off on this, the main/most common issue with this is the warning that we can't store more than a certain size of data in cookies, but cookie chunking should resolve that.

@ping-maxwell commented on GitHub (Oct 19, 2025): Hmm it's possible this is okay to support but I feel like there are possibly a lot of nuances that aren't considered. Maybe for now hold off on this, the main/most common issue with this is the warning that we can't store more than a certain size of data in cookies, but cookie chunking should resolve that.
GiteaMirror commented 2026-03-13 09:29:52 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Oct 19, 2025):

@gottfrois Will cookie chunking resolve your overall issue? or do you specifically require the ability to exclude fields in cookie cache for some reason

@ping-maxwell commented on GitHub (Oct 19, 2025): @gottfrois Will cookie chunking resolve your overall issue? or do you specifically require the ability to exclude fields in cookie cache for some reason
GiteaMirror commented 2026-03-13 09:29:53 -05:00
Author
Owner
Copy Link

@gottfrois commented on GitHub (Oct 20, 2025):

I think both would give someone all the flexibility one need. I don't think storing the user's base64 encoded avatar in a cookie makes any sense, cookie being chunked or not, what do you think?

@gottfrois commented on GitHub (Oct 20, 2025): I think both would give someone all the flexibility one need. I don't think storing the user's base64 encoded avatar in a cookie makes any sense, cookie being chunked or not, what do you think?
GiteaMirror commented 2026-03-13 09:29:53 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Oct 21, 2025):

I think that if chunking resolves the issue of storing too large of data in cookies then there shouldn't be a worry for needing to exclude a specific field. Right now our issue is about storing too large of data within a cookie, so since this can be solved with chunking I don't think it's enough reason to also support excluding fields.

However it's possible there are other better reasons out there not to store a specific field in cookie cache - though I can't think of any as of now.

@ping-maxwell commented on GitHub (Oct 21, 2025): I think that if chunking resolves the issue of storing too large of data in cookies then there shouldn't be a worry for needing to exclude a specific field. Right now our issue is about storing too large of data within *a* cookie, so since this can be solved with chunking I don't think it's enough reason to also support excluding fields. However it's possible there are other better reasons out there not to store a specific field in cookie cache - though I can't think of any as of now.
GiteaMirror commented 2026-03-13 09:29:53 -05:00
Author
Owner
Copy Link

@Blackmamoth commented on GitHub (Oct 21, 2025):

Tbh, field exclusion only seems to make sense for creating lighter cookies, other than that it does seem redundant, maybe I rushed a little for the implementation

@Blackmamoth commented on GitHub (Oct 21, 2025): Tbh, field exclusion only seems to make sense for creating lighter cookies, other than that it does seem redundant, maybe I rushed a little for the implementation
GiteaMirror commented 2026-03-13 09:29:54 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Nov 8, 2025):

Cookie chunking coming to 1.4

@ping-maxwell commented on GitHub (Nov 8, 2025): Cookie chunking coming to 1.4
GiteaMirror commented 2026-03-13 09:29:54 -05:00
Author
Owner
Copy Link

@matteobad commented on GitHub (Nov 23, 2025):

I think this is still relavant, beacause now with cookie chunking we can trigger a 431 Resquest Header Field Too Large

Or am I missing something @ping-maxwell ?

@matteobad commented on GitHub (Nov 23, 2025): I think this is still relavant, beacause now with cookie chunking we can trigger a **431 Resquest Header Field Too Large** Or am I missing something @ping-maxwell ?
GiteaMirror commented 2026-03-13 09:29:54 -05:00
Author
Owner
Copy Link

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

Hey @ping-maxwell,

I'm migrating my enterprise's Next 16 app from Next-Auth v4 to Better-Auth v1.4.

We utilize stateless sessions due to our in-house SSO solution that we must integrate with. I'm currently using genericOAuth, but this reddit issue is quite similar. I encountered a 431 error (locally none of this work has been deployed), because the response from the SSO provider contains a significant amount of information, such as RBAC-style permissions for various departments within the company, along with an access token, etc.

In Next-Auth v4, the jwt callback allows users to set the token with the desired information. However, I have been unable to find a similar functionality in Better-Auth as I attempt to migrate. Neither the migration guide nor an LLM utilizing context7 has been able to identify a method to achieve this functionality.

@taymoork2 commented on GitHub (Jan 13, 2026): Hey @ping-maxwell, I'm migrating my enterprise's Next 16 app from Next-Auth v4 to Better-Auth v1.4. We utilize stateless sessions due to our in-house SSO solution that we must integrate with. I'm currently using `genericOAuth`, but this [reddit issue](https://www.reddit.com/r/better_auth/comments/1podudb/login_with_microsoft_entra_id/) is quite similar. I encountered a `431` error (locally none of this work has been deployed), because the response from the SSO provider contains a significant amount of information, such as RBAC-style permissions for various departments within the company, along with an access token, etc. In Next-Auth v4, the [`jwt` callback](https://next-auth.js.org/configuration/callbacks#jwt-callback) allows users to set the token with the desired information. However, I have been unable to find a similar functionality in Better-Auth as I attempt to migrate. Neither the [migration guide](https://www.better-auth.com/docs/guides/next-auth-migration-guide) nor an LLM utilizing context7 has been able to identify a method to achieve this functionality.
GiteaMirror commented 2026-03-13 09:29:54 -05:00
Author
Owner
Copy Link

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

For Microsoft provider users experiencing cookie size issues:

You can use disableProfilePhoto: true to prevent the base64-encoded avatar from being stored:

export const auth = betterAuth({
  ...
  socialProviders: {
    microsoft: {
      ...
      disableProfilePhoto: true,
    }
  }
});

Alternatively, you can implement a custom getUserInfo callback and simply omit the image field from the returned user object.

Regarding the 431 error:

We're also hitting this issue in our stateless setup with Azure AD. The account_data cookies are ~8.8KB because Better Auth stores the full OAuth tokens (accessToken, idToken, refreshToken) internally via setAccountCookie.

The only workaround we've found is setting storeAccountCookie: false, which prevents the 431 error but also means we lose access to account data in stateless mode.

It would be great if Better Auth could support:

  1. Excluding certain fields from account cookie (e.g., idToken which is often large)
  2. Or a configurable size limit that gracefully degrades instead of triggering 431
@liby commented on GitHub (Jan 14, 2026): For Microsoft provider users experiencing cookie size issues: You can use [`disableProfilePhoto: true`](https://github.com/better-auth/better-auth/blob/07b7ecf80862df7c01fc0e15fe0f633b09133657/packages/core/src/social-providers/microsoft-entra-id.ts#L193) to prevent the base64-encoded avatar from being stored: ```ts export const auth = betterAuth({ ... socialProviders: { microsoft: { ... disableProfilePhoto: true, } } }); ``` Alternatively, you can implement a custom `getUserInfo` callback and simply omit the image field from the returned user object. --- Regarding the 431 error: We're also hitting this issue in our stateless setup with Azure AD. The `account_data` cookies are ~8.8KB because Better Auth stores the full OAuth tokens (`accessToken`, `idToken`, `refreshToken`) internally via `setAccountCookie`. The only workaround we've found is setting `storeAccountCookie: false`, which prevents the 431 error but also means we lose access to account data in stateless mode. It would be great if Better Auth could support: 1. Excluding certain fields from account cookie (e.g., `idToken` which is often large) 2. Or a configurable size limit that gracefully degrades instead of triggering 431
GiteaMirror commented 2026-03-13 09:29:55 -05:00
Author
Owner
Copy Link

@taymoork2 commented on GitHub (Jan 21, 2026):

@liby @ping-maxwell storeAccountCookie: false is the only workaround right now, however, like @liby said, you don't get access to account data

@taymoork2 commented on GitHub (Jan 21, 2026): @liby @ping-maxwell `storeAccountCookie: false` is the only workaround right now, however, like @liby said, you don't get access to account data
GiteaMirror commented 2026-03-13 09:29:55 -05:00
Author
Owner
Copy Link

@gavinhow commented on GitHub (Feb 12, 2026):

Jumping on the back of this issue as its related. We are using microsoft social provider as well. We are getting intermittent behaviour of the inclusion of the raw field in cookie which is the difference between getting a 431 and not. When raw is included it means we have a copy of the account data from within the account data effectively duplicating the size and making it too big.

I've tried looking through the code but can't find the location of where this logic exists.

https://github.com/better-auth/better-auth/blob/canary/packages/core/src/oauth2/utils.ts

export function getOAuth2Tokens(data: Record<string, any>): OAuth2Tokens {
	const getDate = (seconds: number) => {
		const now = new Date();
		return new Date(now.getTime() + seconds * 1000);
	};

	return {
		tokenType: data.token_type,
		accessToken: data.access_token,
		refreshToken: data.refresh_token,
		accessTokenExpiresAt: data.expires_in
			? getDate(data.expires_in)
			: undefined,
		refreshTokenExpiresAt: data.refresh_token_expires_in
			? getDate(data.refresh_token_expires_in)
			: undefined,
		scopes: data?.scope
			? typeof data.scope === "string"
				? data.scope.split(" ")
				: data.scope
			: [],
		idToken: data.id_token,
		// Preserve the raw token response for provider-specific fields
		raw: data,
	};
}

Here is where its setting the raw data but I couldnt' understand why it is sometimes included and sometimes not. Any tips on how to make this behaviour more consistent would be appreciated. or a more sustainable solution like mentioned above.

Update

Looking into it more, its odd behaviour, the two payloads are similar but definitely different. You can see from the sample below. One has processed fields like scopes, tokenType and the raw. The smaller has info like userId and createdAt

Smaller payload

{
    "accessToken": "<REDACTED_ACCESS_TOKEN>",
    "accessTokenExpiresAt": "2026-01-01T00:00:00.000Z",
    "accountId": "<REDACTED_ACCOUNT_ID>",
    "createdAt": "2026-01-01T00:00:00.000Z",
    "exp": 1700000000,
    "iat": 1699996400,
    "id": "<REDACTED_SESSION_ID>",
    "idToken": "<REDACTED_ID_TOKEN>",
    "jti": "00000000-0000-0000-0000-000000000000",
    "providerId": "microsoft",
    "scope": "api://00000000-0000-0000-0000-000000000000/API.Access,api://00000000-0000-0000-0000-000000000000/Application.Access,api://00000000-0000-0000-0000-000000000000/.default",
    "updatedAt": "2026-01-01T00:00:00.000Z",
    "userId": "<REDACTED_USER_ID>"
}

Larger

{
    "accessToken": "<REDACTED_ACCESS_TOKEN>",
    "accessTokenExpiresAt": "2026-01-01T00:00:00.000Z",
    "accountId": "<REDACTED_ACCOUNT_ID>",
    "exp": 1700003600,
    "iat": 1700000000,
    "idToken": "<REDACTED_ID_TOKEN>",
    "jti": "11111111-2222-3333-4444-555555555555",
    "providerId": "microsoft",
    "raw": {
        "access_token": "<REDACTED_ACCESS_TOKEN>",
        "expires_in": 3600,
        "ext_expires_in": 3600,
        "id_token": "<REDACTED_ID_TOKEN>",
        "scope": "api://00000000-0000-0000-0000-000000000000/API.Access api://00000000-0000-0000-0000-000000000000/Application.Access api://00000000-0000-0000-0000-000000000000/.default",
        "token_type": "Bearer"
    },
    "scope": "api://00000000-0000-0000-0000-000000000000/API.Access,api://00000000-0000-0000-0000-000000000000/Application.Access,api://00000000-0000-0000-0000-000000000000/.default",
    "scopes": [
        "api://00000000-0000-0000-0000-000000000000/API.Access",
        "api://00000000-0000-0000-0000-000000000000/Application.Access",
        "api://00000000-0000-0000-0000-000000000000/.default"
    ],
    "tokenType": "Bearer"
}
@gavinhow commented on GitHub (Feb 12, 2026): Jumping on the back of this issue as its related. We are using `microsoft` social provider as well. We are getting intermittent behaviour of the inclusion of the `raw` field in cookie which is the difference between getting a 431 and not. When `raw` is included it means we have a copy of the account data from within the account data effectively duplicating the size and making it too big. I've tried looking through the code but can't find the location of where this logic exists. https://github.com/better-auth/better-auth/blob/canary/packages/core/src/oauth2/utils.ts ```ts export function getOAuth2Tokens(data: Record<string, any>): OAuth2Tokens { const getDate = (seconds: number) => { const now = new Date(); return new Date(now.getTime() + seconds * 1000); }; return { tokenType: data.token_type, accessToken: data.access_token, refreshToken: data.refresh_token, accessTokenExpiresAt: data.expires_in ? getDate(data.expires_in) : undefined, refreshTokenExpiresAt: data.refresh_token_expires_in ? getDate(data.refresh_token_expires_in) : undefined, scopes: data?.scope ? typeof data.scope === "string" ? data.scope.split(" ") : data.scope : [], idToken: data.id_token, // Preserve the raw token response for provider-specific fields raw: data, }; } ``` Here is where its setting the raw data but I couldnt' understand why it is sometimes included and sometimes not. Any tips on how to make this behaviour more consistent would be appreciated. or a more sustainable solution like mentioned above. **Update** Looking into it more, its odd behaviour, the two payloads are similar but definitely different. You can see from the sample below. One has processed fields like `scopes`, `tokenType` and the `raw`. The smaller has info like `userId` and `createdAt` Smaller payload ```json { "accessToken": "<REDACTED_ACCESS_TOKEN>", "accessTokenExpiresAt": "2026-01-01T00:00:00.000Z", "accountId": "<REDACTED_ACCOUNT_ID>", "createdAt": "2026-01-01T00:00:00.000Z", "exp": 1700000000, "iat": 1699996400, "id": "<REDACTED_SESSION_ID>", "idToken": "<REDACTED_ID_TOKEN>", "jti": "00000000-0000-0000-0000-000000000000", "providerId": "microsoft", "scope": "api://00000000-0000-0000-0000-000000000000/API.Access,api://00000000-0000-0000-0000-000000000000/Application.Access,api://00000000-0000-0000-0000-000000000000/.default", "updatedAt": "2026-01-01T00:00:00.000Z", "userId": "<REDACTED_USER_ID>" } ``` Larger ```json { "accessToken": "<REDACTED_ACCESS_TOKEN>", "accessTokenExpiresAt": "2026-01-01T00:00:00.000Z", "accountId": "<REDACTED_ACCOUNT_ID>", "exp": 1700003600, "iat": 1700000000, "idToken": "<REDACTED_ID_TOKEN>", "jti": "11111111-2222-3333-4444-555555555555", "providerId": "microsoft", "raw": { "access_token": "<REDACTED_ACCESS_TOKEN>", "expires_in": 3600, "ext_expires_in": 3600, "id_token": "<REDACTED_ID_TOKEN>", "scope": "api://00000000-0000-0000-0000-000000000000/API.Access api://00000000-0000-0000-0000-000000000000/Application.Access api://00000000-0000-0000-0000-000000000000/.default", "token_type": "Bearer" }, "scope": "api://00000000-0000-0000-0000-000000000000/API.Access,api://00000000-0000-0000-0000-000000000000/Application.Access,api://00000000-0000-0000-0000-000000000000/.default", "scopes": [ "api://00000000-0000-0000-0000-000000000000/API.Access", "api://00000000-0000-0000-0000-000000000000/Application.Access", "api://00000000-0000-0000-0000-000000000000/.default" ], "tokenType": "Bearer" } ```
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 enhancement
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#2139
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?