How to handle Third Party Initiated Login with Passport Strategy

[mastermatt]

I'm working on a Okta initiated login and seeing an error I wasn't expecting. Okta will send an iss query param as per section 4 of the spec, however, that triggers openid-client into starting the auth response flow instead of the auth request flow.

eg. a call to https://my-org.com/login/sso/some-idp-id?iss=https%3A%2F%2Fsome-org.okta.com results in the error: "did not find expected authorization request details in session, req.session["oidc:some-org.okta.com"] is undefined"

Here is the smallest reproduction I came up with:

const app = express()
app.use(session({ secret: 'cat' }))
app.use(passport.initialize())
app.use(passport.session())

// memoized
async function getStrategy(idpSlug) {
  const {
    authorizationParams,
    clientMetadata,
    discoveryUrl,
  } = await getConfigForIdp(idpSlug)

  const issuer = await Issuer.discover(discoveryUrl)
  const client = new issuer.Client(clientMetadata)
  const strategy = new Strategy(
    {
      client,
      params: authorizationParams,
    },
    async (tokenSet, done) => {
      /* ... */
      done(null, {/* ... */})
    }
  )

  const name = `oidc:${idpSlug}`
  passport.use(name, strategy)
  return name
}

app.get('/login/sso/:idpSlug', async (req, res, next) => {
  const { idpSlug } = req.params
  const strategyName = await getStrategy(idpSlug)

  passport.authenticate(strategyName)(req, res, next)
})

app.get('/login/sso/:idpSlug/callback', async (req, res, next) => {
  const { idpSlug } = req.params
  const strategyName = await getStrategy(idpSlug)

  passport.authenticate(strategyName, {
    successRedirect: '/ok',
    failureRedirect: '/bad',
  })(req, res, next)
})

app.listen(/* ... */)

In my case I'll be using dedicated URL paths for each IdP, so my code has no need for the iss param.
I think I expected openid-client to assert the iss against the Issuer or ignore it.

My impression is that this is a bug or missing feature from the library itself.
Currently, my only option would be to override the IncomingMessage.url by stripping the query, but that seems like kludge.
Which direction should I go?

[mastermatt]

@panva could I get your opinion on how this should be behave?

[mastermatt]

@panva circling back to this, I'm still unsure if mutating the IncomingMessage.url to strip off any query string is the expected solution for consumers. Thoughts?

[mastermatt]

#564