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

[GH-ISSUE #6583] getSession behaves differently from the document #10561

New Issue
Closed
opened 2026-04-13 06:47:11 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-13 06:47:11 -05:00
Owner
Copy Link

Originally created by @luoling8192 on GitHub (Dec 7, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/6583

Describe the bug

When using bearer as the session strategy, auth.api.getSession({ headers }) completely ignores the Authorization: Bearer <token> header and always returns null, even when a valid token is present.

This behavior contradicts the official documentation which states that getSession should automatically support both cookie-based sessions and Bearer token authentication.

The document said

https://www.better-auth.com/docs/plugins/bearer#5-using-bearer-tokens-outside-the-auth-client

And in the server, you can use the auth.api.getSession function to authenticate requests:

import { auth } from "@/auth";
export async function handler(req, res) {
  const session = await auth.api.getSession({
    headers: req.headers
  });
  
  if (!session) {
    return res.status(401).json({ error: "Unauthorized" });
  }
  
  // Process authenticated request
  // ...
}

To Reproduce

  1. Configuration
return betterAuth({
  database: drizzleAdapter(db, { provider: "pg" }),
  plugins: [bearer()],
});
  1. Configure Hono middleware
    Use the recommended middleware pattern from the docs:
app.use('*', async (c, next) => {
  const session = await auth.api.getSession({ headers: c.req.raw.headers })
  // session is always null even when Authorization header contains a valid JWT
  console.log('session', session)
  // ...
})

  1. Send a request with Authorization: Bearer <token> header → getSession returns null.

  2. Cookie-based authentication works fine in the same setup.

Expected behavior

According to the documentation and common industry practice, auth.api.getSession() should:

  • Check cookies first (if cookie strategy enabled)
  • Fall back to reading Authorization: Bearer header
Originally created by @luoling8192 on GitHub (Dec 7, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/6583 # Describe the bug When using bearer as the session strategy, `auth.api.getSession({ headers })` completely ignores the `Authorization: Bearer <token>` header and always returns null, even when a valid token is present. This behavior contradicts the official documentation which states that `getSession` should automatically support both cookie-based sessions and Bearer token authentication. # The document said https://www.better-auth.com/docs/plugins/bearer#5-using-bearer-tokens-outside-the-auth-client And in the server, you can use the `auth.api.getSession` function to authenticate requests: ```ts import { auth } from "@/auth"; export async function handler(req, res) { const session = await auth.api.getSession({ headers: req.headers }); if (!session) { return res.status(401).json({ error: "Unauthorized" }); } // Process authenticated request // ... } ``` # To Reproduce 1. Configuration ```ts return betterAuth({ database: drizzleAdapter(db, { provider: "pg" }), plugins: [bearer()], }); ``` 2. Configure Hono middleware Use the recommended middleware pattern from the docs: ```ts app.use('*', async (c, next) => { const session = await auth.api.getSession({ headers: c.req.raw.headers }) // session is always null even when Authorization header contains a valid JWT console.log('session', session) // ... }) ``` 3. Send a request with `Authorization: Bearer <token>` header → getSession returns null. 4. Cookie-based authentication works fine in the same setup. # Expected behavior According to the documentation and common industry practice, auth.api.getSession() should: - Check cookies first (if cookie strategy enabled) - Fall back to reading Authorization: Bearer <token> header
GiteaMirror added the lockedbug labels 2026-04-13 06:47:11 -05:00
GiteaMirror commented 2026-04-13 06:47:13 -05:00
Author
Owner
Copy Link

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

Hi there! Thanks for raising this issue. Based on your description, when using the JWT session strategy, getSession should indeed fall back to reading the Authorization header if a cookie isn’t present, as documented. Here are a few troubleshooting steps you can try:

• First, verify that your Authorization header is correctly formatted ("Authorization: Bearer ") and that the token is valid and signed by your configured signer. This matches our recommended approach for using Bearer tokens outside the auth client [1].

• Make sure that your Better Auth configuration is correctly set up for JWT. If you’ve disabled the cookie strategy or are running in mixed mode, double-check that the Bearer plugin is active and properly integrated so that getSession can pick up the token from the header.

• It may also help to log the raw headers received by getSession to ensure that the Authorization header isn’t being altered or dropped by any middleware before it reaches Better Auth.

If after these steps you’re still experiencing issues, there might be an edge case or a regression that we need to investigate further. Would you be able to share any additional logs or configuration details (without sensitive data) to help narrow it down? Tag @bekacru and @ping__ if you’d like further help from the team.

tag @better-auth-agent if you would like an answer from the Agent

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:3621976245 --> @better-auth-agent[bot] commented on GitHub (Dec 7, 2025): Hi there! Thanks for raising this issue. Based on your description, when using the JWT session strategy, getSession should indeed fall back to reading the Authorization header if a cookie isn’t present, as documented. Here are a few troubleshooting steps you can try: • First, verify that your Authorization header is correctly formatted ("Authorization: Bearer <token>") and that the token is valid and signed by your configured signer. This matches our recommended approach for using Bearer tokens outside the auth client [[1]](https://www.better-auth.com/docs/plugins/bearer). • Make sure that your Better Auth configuration is correctly set up for JWT. If you’ve disabled the cookie strategy or are running in mixed mode, double-check that the Bearer plugin is active and properly integrated so that getSession can pick up the token from the header. • It may also help to log the raw headers received by getSession to ensure that the Authorization header isn’t being altered or dropped by any middleware before it reaches Better Auth. If after these steps you’re still experiencing issues, there might be an edge case or a regression that we need to investigate further. Would you be able to share any additional logs or configuration details (without sensitive data) to help narrow it down? Tag @bekacru and @ping__ if you’d like further help from the team. tag @better-auth-agent if you would like an answer from the Agent _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/skyvern_ultra_detailed_interactive.html) • [Discord](https://discord.gg/fG2XXEuQX3) • [GitHub](https://github.com/Skyvern-AI/Skyvern) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/skyvern_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/fG2XXEuQX3) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/Skyvern-AI/Skyvern)
GiteaMirror commented 2026-04-13 06:47:13 -05:00
Author
Owner
Copy Link

@luoling8192 commented on GitHub (Dec 7, 2025):

Here is the related discussion: https://www.answeroverflow.com/m/1379095607716872302

<!-- gh-comment-id:3621976625 --> @luoling8192 commented on GitHub (Dec 7, 2025): Here is the related discussion: https://www.answeroverflow.com/m/1379095607716872302
GiteaMirror commented 2026-04-13 06:47:14 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Dec 8, 2025):

is the bearer token a session token or a jwt?

<!-- gh-comment-id:3624168141 --> @Bekacru commented on GitHub (Dec 8, 2025): is the bearer token a session token or a jwt?
GiteaMirror commented 2026-04-13 06:47:15 -05:00
Author
Owner
Copy Link

@luoling8192 commented on GitHub (Dec 8, 2025):

is the bearer token a session token or a jwt?

it's the session token, don't work at all

<!-- gh-comment-id:3625194338 --> @luoling8192 commented on GitHub (Dec 8, 2025): > is the bearer token a session token or a jwt? it's the session token, don't work at all
GiteaMirror commented 2026-04-13 06:47:15 -05:00
Author
Owner
Copy Link

@bytaesu commented on GitHub (Feb 1, 2026):

Hi @luoling8192,

I tested. but couldn't reproduce this issue. I think this is probably related to encoding or casing, so I've made the handling more flexible. If the problem persists, feel free to mention me anytime 🙂

<!-- gh-comment-id:3830712465 --> @bytaesu commented on GitHub (Feb 1, 2026): Hi @luoling8192, I tested. but couldn't reproduce this issue. I think this is probably related to encoding or casing, so I've made the handling more flexible. If the problem persists, feel free to mention me anytime 🙂
GiteaMirror commented 2026-04-13 06:47:16 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 1, 2026):

This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.

<!-- gh-comment-id:4166556405 --> @github-actions[bot] commented on GitHub (Apr 1, 2026): This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.
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#10561
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?