Passport strategy broken with iss in authentication request

[trombonekenny]

5.0.0 introduced OAuth 2.0 authorization server issuer checking which has a side effect of causing the passport strategy to process authentication requests with iss in them as if they were responses instead of requests.

This errors with a did not find expected authorization request details in session, req.session['foo'] is undefined

I believe this is happening because iss is (as of 5.0.0) listed here:

node-openid-client/lib/client.js

Line 53 in 363c215

'iss', // draft-ietf-oauth-iss-auth-resp

which causes the if here always fails and we pass into authentication response.

node-openid-client/lib/passport_strategy.js

Line 88 in 363c215

if (Object.keys(reqParams).length === 0) {

To Reproduce
Steps to reproduce the behaviour:

1. Setup a passport strategy with openid-client
2. Send an authentication request that has the iss property present

Expected behaviour
I'm currently working around this by doing a delete req.body.iss in my authentication request route before calling passport.authenticate. Then it behaves like the 4.9.1 version and processes the authentication request properly.

Environment:

• openid-client version: 5.3.2

Additional context
The draft, now RFC9207 doesn't talk about authentication requests, only responses. That leads me to believe this is a bug.

The LTI 1.3 security framework is an example of a spec that says iss is required in the third-party initiated login authentication request.

• the bug is happening on latest openid-client too.
• I have searched the issues tracker on github for similar issues and couldn't find anything related.

[panva]

The draft, now RFC9207 doesn't talk about authentication requests, only responses. That leads me to believe this is a bug.

Exactly, because this is an authorization response parameter it makes iss listed as "callback" parameter, which means when present in the query the strategy flows to the "callback" code path.

That leads me to believe this is a bug.

Why?

[trombonekenny]

That leads me to believe this is a bug.

Why?

Because iss can also come in via an authentication request, per the LTI spec I posted. The presence of iss doesn't necessarily mean it is an authentication response. I believe in a response, it should validate the iss like the RFC recommends. But it's presence shouldn't be used by the passport strategy to determine if the .authenticate() is processing a request or response.

[trombonekenny]

Thanks for the quick response! I didn't see that you'd made a patch so quickly when this closed. 😃