Add ability to specify OAuth endpoints

[scotttrinh]

If your database is deployed to a private network and is not available at a public URL, this adds the ability to drive the whole flow from your application server, delegating to the auth server from your application server.

---

When testing this manually, I set up a new route handler at /auth/oauth that shadows the one built into our createAuthRouteHandlers behavior like this:

export async function GET(request: NextRequest): Promise<NextResponse> {
  const callbackUrl = new URL("auth/server/oauth/callback", authConfig.baseUrl);
  const authorizeUrl = new URL(
    "auth/server/oauth/authorize",
    authConfig.baseUrl,
  );
  request.nextUrl.searchParams.set("callback_url", callbackUrl.toString());
  request.nextUrl.searchParams.set("authorize_url", authorizeUrl.toString());

  return await auth.oAuth.handleOAuth(request);
}

Which set the authorize and callback URLs explicitly to routes in my application, and then those route handlers simply called through to these new methods like:

//  app/auth/server/oauth/authorize.ts
export async function GET(request: NextRequest): Promise<NextResponse> {
  return await auth.oAuth.handleAuthorize(request);
}

// app/auth/server/oauth/callback.ts
export async function GET(request: NextRequest): Promise<NextResponse> {
  return await auth.oAuth.handleCallback(request);
}

Of course, instead of just calling this methods, one could do any kind of check here on the request if your intention is to add some behavior here (analytics? logic? check email against an invite list?)

[jaclarke]

Suggested change

console.log(`Redirecting to ${location}`);

[jaclarke]

Should this (and callback_url) be args to this handleOAuth function? I'm not sure they are meant to be something the user should be able to control? and in the example usage thay're appended to the req right before it's passed to this function anyway.

[scotttrinh]

The API I'm going for here is that these "handler" functions should always take a NextRequest and return a Promise<NextResponse> in a middleware like fashion. An alternative way to do this is to be more explicit about what parameters we explicitly depend on within the function itself, but I'm worried that it adds boilerplate of getting the data we need from the request. I can sketch that out though and see how that feels in actual use though.

[jaclarke]

Ok, maybe strip out those two values from the search params here: https://github.com/edgedb/edgedb-js/pull/1136/files#diff-660934b707fc817f8bd5cef3341ffb7f24ffc16f9e200843c762e384e2820c41L173 then? I haven't fully thought out the whole flow and there probably isn't an attack you could do using these params, but just to be safe maybe 😄.

[scotttrinh]

Ok, maybe strip out those two values from the search params here: #1136 (files) then?

Maybe I'm not understanding the suggestion but these parameters will be present in the URL that the browser uses as a link, just like provider, and it needs to be passed all the way to the auth extension. It's not something an end user needs to worry about, but the application developer will absolutely need to set this either in the link button's URL, or manually in their own backend like I did in my example.

I haven't fully thought out the whole flow and there probably isn't an attack you could do using these params, but just to be safe

The URLs are checked against the allowed_redirect_urls config, so if there is an attack vector there, the attack also exists in the existing redirect_to search parameters.