Custom startRedirectPath + callbackUri

[alexcroox]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

It would be useful if there was a way to define the route and callback URI ourselves in runtime, rather than once at boot.

For example if calling from the web I'd want for the callback: https://example.com/login/google/callback

But for my native apps calling the same API I'd use the app identifier appname://login/google/callback

Unless I'm missing something this isn't possible with the current API.

Motivation

Serve both web and native apps with the same code

Example

app.get('/auth/login/google', { schema: oauthGoogleSchema }, async function loginGoogleHandler(request, response) {
  const loginUrl = oauthPlugin.getLoginUrl({
    {
    name: 'googleOAuth2',
    credentials: {
      client: {
        id: '<CLIENT_ID>',
        secret: '<CLIENT_SECRET>'
      },
      auth: oauthPlugin.GOOGLE_CONFIGURATION,
      callbackUri: request.query.callbackUri
    }
  })

  response.redirect(loginUrl)
})

[climba03003]

You cannot have dynamic path in fastify otherwise, it would be a wildcard one.
Use a static endpoint and redirect inside that endpoint.

[alexcroox]

Thank you, I was confused with the flow.

[patrick-petrovic]

Hi @climba03003, I think this feature would still be useful because you might want your application to be accessible from multiple domains (e.g., during a migration). At the moment you would need one instance of this module per hostname. Any opinions on this?

[climba03003]

Hi @climba03003, I think this feature would still be useful because you might want your application to be accessible from multiple domains (e.g., during a migration). At the moment you would need one instance of this module per hostname. Any opinions on this?

I don't know why you don't do something like this?

fastify.register(oauthPlugin, {
  name: 'facebookOAuth2',
  credentials: {
    client: {
      id: '<CLIENT_ID>',
      secret: '<CLIENT_SECRET>'
    },
    auth: oauthPlugin.FACEBOOK_CONFIGURATION
  },
  // facebook redirect here after the user login
  callbackUri: '<replaceme>/login/facebook/callback'
})

fastify.get('/login/facebook', { /* Hooks can be used here */ }, async (req, reply) => {
  const authorizationEndpoint = fastify.facebookOAuth2.generateAuthorizationUri(req);
  
  authorizationEndpoint.replace('<replaceme>', req.protocol + '://' + req.host)
  
  reply.redirect(authorizationEndpoint)
});

[patrick-petrovic]

@climba03003 Yup, that's very similar to what I tried. However, when calling getAccessTokenFromAuthorizationCodeFlow afterwards the module will use <replaceme>/login/facebook/callback. This means there is a mismatch in the redirect URL, which will cause (at least some) OAuth providers to reject the access token request.

[patrick-petrovic]

For reference, my current workaround looks similar to this. It registers one plugin instance per hostname and adds a custom decorator that returns the right plugin instance. This workaround is okay if you have a small number of hostnames and do not need any wildcard support. I think it would still be nice to avoid this workaround in the future though :) Let me know if you're interested in a PR @climba03003!

import oauth, { OAuth2Namespace } from '@fastify/oauth2'
import fastify from 'fastify'
const server = fastify()

const applicationHosts = ['a.example.com', 'b.example.com']
const callbackPath = '/oauth/callback'

for (const host of applicationHosts) {
  const fullRedirectUri = `${host}${callbackPath}`
  server.register(oauth, { name: `oauth_${host}`, callbackUri: fullRedirectUri /*, other options */ })
}

server.decorate('oauth', {
  getForHost: (host: string) => {
    if (!applicationHosts.includes(host)) {
      throw new Error('no OAuth client for host')
    }
    return (server as unknown as Record<string, OAuth2Namespace>)[`oauth_${host}`]
  }
})

Then you can the plugin instance via server.oauth.getForHost(req.headers.host) at runtime.

[Uzlopak]

@ppati000

In fastify development, if it is easier to provide a PR or means a small time investment, than provide a PR. If it is a big feature or breaking change, then we should discuss it before providing a PR, which is alot of work or takes a long time to create.

So if it is a small time investment, than provide the PR. We will review it accordingly and if it is good, merge and publish.

[wlinna]

This feature would be very useful. It is very common to have different versions of the same server at different domains. For example, in Google App Engine you'd have domains that look like

<version>-dot-<app_name>.appspot.com.

You can at any time make any of the versions the main version, which will then be served in the domain.

<app_name>.appspot.com

Not to mention that it's also common to point a custom domain to this url.

So if it's possible to implement a request-time callbackUri-selection, I think it should be. I'm not an oauth expert though.

Meanwhile I'll try ppati's workaround

[wlinna]

Hi @climba03003, I think this feature would still be useful because you might want your application to be accessible from multiple domains (e.g., during a migration). At the moment you would need one instance of this module per hostname. Any opinions on this?

I don't know why you don't do something like this?

fastify.register(oauthPlugin, {
  name: 'facebookOAuth2',
  credentials: {
    client: {
      id: '<CLIENT_ID>',
      secret: '<CLIENT_SECRET>'
    },
    auth: oauthPlugin.FACEBOOK_CONFIGURATION
  },
  // facebook redirect here after the user login
  callbackUri: '<replaceme>/login/facebook/callback'
})

fastify.get('/login/facebook', { /* Hooks can be used here */ }, async (req, reply) => {
  const authorizationEndpoint = fastify.facebookOAuth2.generateAuthorizationUri(req);
  
  authorizationEndpoint.replace('<replaceme>', req.protocol + '://' + req.host)
  
  reply.redirect(authorizationEndpoint)
});

I see that generateAuthorizationUri uses the callbackUri that was originally provided in options. Perhaps generateAuthorizationUri could be modified to take its own options object where callers could override callbackUri ?

EDIT: I just realized that the problem was that it was getAccessTokenFromAuthorizationCodeFlow where the callbackUri was problematic.

[wlinna]

One solution I came up with, which I'm going to be using for now, is to make a custom version of fastify-oauth2 where callbackUri is either a string or a function that takes a fastify Request as an argument. The changes were rather minimal.

Then I just configure it like this:

callbackUri: (req: FastifyRequest) => `${req.protocol}://${req.hostname}/api/session/callback`

[climba03003]

I would say that if you have idea on new interface, please open new issue to discuss.
I am open to the improvement.

[wlinna]

Thank you for your comment. As you can see, I have written a feature request and have mentioned this issue there