I just realized I could do this instead

OAuth2Strategy.prototype.authorizationParams = function(options) {
    return { selected_idp: options.idp }
}
router.get('/signin', function(req, res, next) {
    passport.authenticate('oauth2', {
        //this will be used by my authorizationParams() and selected_idp will be injected to authorized url
        idp: req.query.idp
    })(req, res, next);
});

Is there any side effect from Javascript closure?

+1 for a way to allow arbitrary parameters in the authorisation URL. For instance, if req could be passed to the call to authorizationParams (eg https://github.com/jaredhanson/passport-oauth2/blob/master/lib/strategy.js#L216) would allow returning params and values based upon the request, session, user etc. In my use case, my OAuth provider takes a variety of different parameters and because I'm authorize()'ing an existing user, I'd want to pass the user's attributes (from the request session).

What @soichih suggests with authenticate() is an option -- perhaps a second level of customisation -- but at least initially it having the Strategy pass the request to its authorizationParams function would make it simpler than having to create separate closures/callbacks.

Agreed, and there is also the claims parameter which doesn't seem to be supported at the moment. The most convenient way to support it would be giving it as an option like you do with scope and state params.

A workaround here is to directly pass any custom params into the authorization URL. These will be merged into the authorization URL this package generates:

In a case you even cannot pass data as @soichih sugests, you can access the request object using this ugly nasty never-use-that way:

passportOAuth.Strategy.prototype.authorizationParams = function() {
    const req = passportOAuth.Strategy.prototype.authorizationParams.caller.arguments[0];
    // do whatever you need
}

I will create a pull request to avoid this ugly hack, hope it will be merged soon.