RPError in kubernetes production environment

[Gumbee]

Describe the bug When using node-openid-client with passport and node-oidc-provider as provider, passport fails to authenticate (and it seems the verify callback is never even called) and contains data of the form {"name": "RPError", "jwt": "somejwtdata"} inside the callback of passport's authenticate. This however only occurs when the applications are deployed to production (we are using a kubernetes cluster on google cloud). Locally everything works (even when locally running the applications in production environment)

Snippet

public handleLogin = passport.authenticate('oidc');
public handleCallback = async (req: Request, res: Response, next: NextFunction) => {
  passport.authenticate('oidc', async (err, user, info) => {
    // err is null
    // user is false
    // info contains {"name": "RPError", "jwt": "somejwtdata"}

    if (err) {
      return next(err);
    }

    if (!user) return next(new HttpException(403, 'No user found'));

    return someLogic(req, res, user);
  })(req, res, next);
};

Expected behaviour Inside the passport authenticate callback, user should be populated with the correct user and info should not contain some weird error name and a jwt token when in production.

Environment:

• openid-client version: 5.1.1
• oidc-provider version: 7.10.4
• node version: 16.13.2

Additional context

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

[panva]

The strategy calls either passport's .fail or .error, in your case it's .fail. You're only providing part of the data, e.g. the RPError instance message and stack trace would tell you more.

My guess is that timestamp validations are failing because of incorrectly set system time. Can't say without more details, you may start by setting a clock skew of 60 seconds.

That being said it's an RPError, ergo an assertion failure, and not a bug.

[Gumbee]

Found the issue. The kubernetes deployment was using localhost as jwt issuer. Providing the correct issuer solved the issue. Thank you for your quick reply!