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 #4485] Issue with Better Auth Sign-In Social API for Google Provider – ID Token Not Creating Account and not Returning Session from mobile app #27275

New Issue
Closed
opened 2026-04-17 18:12:22 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-17 18:12:22 -05:00
Owner
Copy Link

Originally created by @Nishchit14 on GitHub (Sep 6, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4485

Description:
We are using the Better Auth Sign-In Social API for Google authentication on the mobile app. Currently, we are generating the idToken from the device side and using it to authenticate through the Google provider. The issue we are facing is that when passing the idToken back to sign-in social api, the API always returns the redirect URL instead of creating the account and returning the session.

POST /sign-in/social

{
    "provider": "google',
   "idToken": "fsdfdsf....
}

response

{
    "redirect": true,
    "url": "htps://...."
}

Steps to Reproduce:

  1. Generate idToken on the mobile device using Google Sign-In.
  2. Pass the generated idToken to the Better Auth Sign-In Social API for Google provider.
  3. Observe the API response.
  4. Instead of returning a session, the API redirects back with a URL.

Expected Behavior:

The API should create the user account (if it doesn’t already exist) and return the user session, not a redirect URL.

Actual Behavior:

The API returns a redirect URL instead of creating the account and returning the session.

Additional Information:

  • The idToken is valid, and we're able to authenticate the user on the device side.

Environment:

  • Mobile app (iOS/Android
Originally created by @Nishchit14 on GitHub (Sep 6, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4485 **Description**: We are using the Better Auth Sign-In Social API for Google authentication on the mobile app. Currently, we are generating the `idToken` from the device side and using it to authenticate through the Google provider. The issue we are facing is that when passing the `idToken` back to sign-in social api, the API always returns the redirect URL instead of creating the account and returning the session. ```ts POST /sign-in/social { "provider": "google', "idToken": "fsdfdsf.... } ``` response ``` { "redirect": true, "url": "htps://...." } ``` ### Steps to Reproduce: 1. Generate `idToken` on the mobile device using Google Sign-In. 2. Pass the generated `idToken` to the Better Auth Sign-In Social API for Google provider. 3. Observe the API response. 4. Instead of returning a session, the API redirects back with a URL. ### Expected Behavior: The API should create the user account (if it doesn’t already exist) and return the user session, not a redirect URL. ### Actual Behavior: The API returns a redirect URL instead of creating the account and returning the session. ### Additional Information: * The `idToken` is valid, and we're able to authenticate the user on the device side. ### Environment: * Mobile app (iOS/Android
GiteaMirror added the locked label 2026-04-17 18:12:22 -05:00
GiteaMirror commented 2026-04-17 18:12:23 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 6, 2025):

The issue is likely caused by the format of your request payload. For direct Google idToken sign-in with Better Auth, the idToken must be sent as an object, not a string. The correct payload is:

{
  "provider": "google",
  "idToken": {
    "token": "your-google-id-token"
  }
}

If you send "idToken": "..." (as a string), the API will ignore it and default to the OAuth redirect flow, returning a redirect URL instead of a session. When you send the idToken as an object with a token property, the API will verify the token, create the account if needed, and return the session directly—no redirect involved (docs, code).

Also, make sure:

  • Your Google provider config in Better Auth includes the correct clientId and clientSecret.
  • The disableIdTokenSignIn option is not set to true in your provider config.

Once you update your request to use the correct format, you should get a session in the response instead of a redirect.

To reply, just mention @dosu.

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

<!-- gh-comment-id:3262089095 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> The issue is likely caused by the format of your request payload. For direct Google idToken sign-in with Better Auth, the idToken must be sent as an object, not a string. The correct payload is: ```json { "provider": "google", "idToken": { "token": "your-google-id-token" } } ``` If you send `"idToken": "..."` (as a string), the API will ignore it and default to the OAuth redirect flow, returning a redirect URL instead of a session. When you send the idToken as an object with a `token` property, the API will verify the token, create the account if needed, and return the session directly—no redirect involved ([docs](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/docs/content/docs/authentication/google.mdx), [code](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/packages/better-auth/src/api/routes/sign-in.ts)). Also, make sure: - Your Google provider config in Better Auth includes the correct `clientId` and `clientSecret`. - The `disableIdTokenSignIn` option is not set to `true` in your provider config. Once you update your request to use the correct format, you should get a session in the response instead of a redirect. <!-- 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/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/d1d1e8c3-6b0c-4f5c-877f-9cbae4898c16?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/4485)
GiteaMirror commented 2026-04-17 18:12:23 -05:00
Author
Owner
Copy Link

@Nishchit14 commented on GitHub (Sep 6, 2025):

@dosu

Here is the request OpenAPI definition

Image
<!-- gh-comment-id:3262138718 --> @Nishchit14 commented on GitHub (Sep 6, 2025): @dosu Here is the request OpenAPI definition <img width="604" height="458" alt="Image" src="https://github.com/user-attachments/assets/9476da5f-ebe4-45b3-862b-db2b2d691725" />
GiteaMirror commented 2026-04-17 18:12:24 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 6, 2025):

The OpenAPI definition you shared lists idToken as a string, but the actual implementation of the /sign-in/social endpoint requires idToken to be an object with a token property. If you send idToken as a string, the API will default to the OAuth redirect flow and return a redirect URL instead of a session.

To sign in directly with a Google idToken, your payload should look like this:

{
  "provider": "google",
  "idToken": {
    "token": "your-google-id-token"
  }
}

This matches the validation and logic in the codebase, which only accepts idToken as an object and will create the account and return the session if the token is valid see implementation.

The OpenAPI definition should be updated to reflect this requirement to avoid confusion. For now, use the object format above for direct sign-in.

To reply, just mention @dosu.

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

<!-- gh-comment-id:3262142667 --> @dosubot[bot] commented on GitHub (Sep 6, 2025): <!-- Answer --> The OpenAPI definition you shared lists `idToken` as a string, but the actual implementation of the `/sign-in/social` endpoint requires `idToken` to be an object with a `token` property. If you send `idToken` as a string, the API will default to the OAuth redirect flow and return a redirect URL instead of a session. To sign in directly with a Google idToken, your payload should look like this: ```json { "provider": "google", "idToken": { "token": "your-google-id-token" } } ``` This matches the validation and logic in the codebase, which only accepts `idToken` as an object and will create the account and return the session if the token is valid [see implementation](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/packages/better-auth/src/api/routes/sign-in.ts). The OpenAPI definition should be updated to reflect this requirement to avoid confusion. For now, use the object format above for direct sign-in. <!-- 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/18d8540d-cde7-4d82-bd53-065e264b0f19?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/18d8540d-cde7-4d82-bd53-065e264b0f19?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/18d8540d-cde7-4d82-bd53-065e264b0f19?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/18d8540d-cde7-4d82-bd53-065e264b0f19?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/18d8540d-cde7-4d82-bd53-065e264b0f19?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/18d8540d-cde7-4d82-bd53-065e264b0f19?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/18d8540d-cde7-4d82-bd53-065e264b0f19?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/4485)
GiteaMirror commented 2026-04-17 18:12:24 -05:00
Author
Owner
Copy Link

@Kinfe123 commented on GitHub (Sep 6, 2025):

Can you pls try on making sure to do the idToken with a correct payload based on the schema options we have here will make sure to fix that..

<!-- gh-comment-id:3262423270 --> @Kinfe123 commented on GitHub (Sep 6, 2025): Can you pls try on making sure to do the idToken with a correct payload based on the schema options we have [here](https://github.com/better-auth/better-auth/blob/a39d09d3ff83b526fb9caf691d3bbcb3b7b2335b/packages/better-auth/src/api/routes/sign-in.ts#L73) will make sure to fix that..
GiteaMirror commented 2026-04-17 18:12:25 -05:00
Author
Owner
Copy Link

@Nishchit14 commented on GitHub (Sep 7, 2025):

God speed. Thank you, It's working now. @Kinfe123

<!-- gh-comment-id:3263544964 --> @Nishchit14 commented on GitHub (Sep 7, 2025): God speed. Thank you, It's working now. @Kinfe123
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 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#27275
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?