[express-oauth2-jwt-bearer] What is the best practice to allow request to go through despite token being unauthorized? about node-oauth2-jwt-bearer HOT 4 CLOSED

As for your first proposed solution, that could work, but I'm afraid of cases such as expired tokens going through. In that case, there would still be an Authorization header set, although the value invalid. I would like the response to still go through, as though you were anonymous user. Is that unreasonable?

No, this still sounds reasonable

On a side note, the option authRequired: false from the package express-openid-connect, as demonstrated here, is probably related to my use case here.

Yeah, this is a good idea. I'll switch this to a feature request, not sure when I can take a look but you should be able to use one of the workarounds in the meantime

from node-oauth2-jwt-bearer.

Hi @nbkhope - thanks for raising this

You could skip this middleware if no authentication is provided on the request.

// untested:
const { auth } = require('express-oauth2-jwt-bearer');

const authIfAvailable = (config) => {
  const mw = auth(config);
  return (req, res, next) => {
    if (!req.headers.authorization) {
      next();
    } else {
      mw(req, res, next)
    }
  }
}

app.use(authIfAvailable());

Does passport have the option to throw/not throw based on something similar? Which Passport strategy are you referring to?

from node-oauth2-jwt-bearer.

I could add a second step in the pipeline just to catch that possible error, but then that error middleware would also catch any other kind of error and would get in the way of my standard error pipeline.

You could also just do

// untested:
const { auth } = require('express-oauth2-jwt-bearer');

const authNoError = (config) => {
  const mw = auth(config);
  return (req, res, next) => {
    mw(req, res, () => next())
  }
}

app.use(authNoError());

from node-oauth2-jwt-bearer.

Thanks for the response, @adamjmcgrath.

One way I got it to work was to add an extra error handler, then rethrow the error if it does not match the error name UnauthorizedError, header, status 401, etc. I still don't like that though.

As for your first proposed solution, that could work, but I'm afraid of cases such as expired tokens going through. In that case, there would still be an Authorization header set, although the value invalid. I would like the response to still go through, as though you were anonymous user. Is that unreasonable?

As for your second proposed solution, I have to try that out and get to understand the () => next() part (at first glancing assuming it would just get rid of the error and letting it through; that could work).

Does passport have the option to throw/not throw based on something similar? Which Passport strategy are you referring to?

The example I used uses passport-jwt, but the actual error handling mechanism that lets me keep the pipeline going is from passport itself, the callback parameter to authenticate():

https://github.com/jaredhanson/passport/blob/cfdbd4a762b51e339ebfea931d65bccbbde53282/lib/middleware/authenticate.js#L34-L42

On a side note, the option authRequired: false from the package express-openid-connect, as demonstrated here, is probably related to my use case here.

from node-oauth2-jwt-bearer.