Additional search params in genericOAuth getToken

[Alvi24]

how can i access additional search params (besides the code searchParam) passed to the callbackUrl in getToken property
because only the code, redirectURI and codeVerifier are available

[dosubot[bot]]

Currently, the getToken function only receives code, redirectURI, and codeVerifier — there's no way to access additional callback URL query parameters from within it [1]. The callback route handler does parse other query params like state, error, etc. [2], but that context isn't forwarded to getToken.

Workaround: If you need to pass custom data through the OAuth flow, you can encode it in the state parameter during the authorization request (via authorizationUrlParams or by customizing the authorization URL). The state is decoded server-side during the callback, but note it still won't be directly available inside getToken — it's used elsewhere in the flow.

If your use case requires the full callback URL params inside getToken, this would need a change to the plugin's type signature to include additional context. You might consider opening a feature request for expanding the getToken arguments to include the full query parameters from the callback URL. The related issue #9040 discusses similar limitations with the generic OAuth plugin's extensibility.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Alvi24]

is there a way to validate search params passed to the callback url?

[dosubot[bot]]

The generic OAuth plugin's callback route uses a strict Zod schema that only validates the standard OAuth parameters (code, state, error, error_description, iss) [1]. Any additional custom query parameters on the callback URL are ignored — there's no hook or config option to validate them.

If you need to pass custom data through the OAuth flow and access it during the callback, the intended approach is to use additionalData when initiating the sign-in. This data gets stored server-side and is recovered during the callback via parseState() [2], rather than being sent as separate query params on the callback URL.

What's your use case — are you trying to validate something your OAuth provider appends to the callback URL, or pass your own custom data through the flow?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Alvi24]

the additional search params are given by the oauth provider and not when initiating sign-in
i want to validate the authorization by checking the hmac search param and two other search params if they are the expected value or not
the search params are passed to /api/auth/oauth2/callback/[providerId]

[dosubot[bot]]

The generic OAuth plugin doesn't expose those extra query params directly, but you can intercept the callback request before the Zod schema strips them away by writing a small custom plugin with a before hook or onRequest hook.

Using a before hook (runs before the endpoint handler):

const hmacValidationPlugin = {
  id: "hmac-validation",
  hooks: {
    before: [
      {
        matcher: (context) => context.path.startsWith("/oauth2/callback/"),
        handler: async (ctx) => {
          const url = new URL(ctx.request.url);
          const hmac = url.searchParams.get("hmac");
          const param1 = url.searchParams.get("your_param_1");
          const param2 = url.searchParams.get("your_param_2");

          // Validate HMAC and other params
          const isValid = validateHmac(hmac, param1, param2);
          if (!isValid) {
            return { response: new Response("Invalid HMAC", { status: 403 }) };
          }
        },
      },
    ],
  },
} satisfies BetterAuthPlugin;

This fires after routing but before the endpoint handler runs [1]. Returning a Response from the hook short-circuits the request.

Alternatively, using onRequest (the earliest interception point, runs before routing):

const hmacValidationPlugin = {
  id: "hmac-validation",
  onRequest: async (request, ctx) => {
    const url = new URL(request.url);
    if (url.pathname.includes("/oauth2/callback/")) {
      const hmac = url.searchParams.get("hmac");
      // ... validate
      if (!valid) {
        return new Response("Forbidden", { status: 403 });
      }
    }
    return { request };
  },
} satisfies BetterAuthPlugin;

[2]

Either approach gives you access to the full URL with all query parameters from the provider before the Zod schema validation runs, so you can validate the HMAC and other params and reject the request if they don't match.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Alvi24]

can you open an issue for this

[Alvi24]

is it better if i use betterAuth hooks and not a plugin
export const auth = betterAuth({
hooks: {
before: createAuthMiddleware(async (ctx) => {
if (ctx.path !== "/sign-up/email") {
return;
}
if (!ctx.body?.email.endsWith("@example.com")) {
throw new APIError("BAD_REQUEST", {
message: "Email must end with @example.com",
});
}
}),
},
});