passport-next / passport-openid

OpenID authentication strategy for Passport and Node.js.
MIT License
6 stars 3 forks source link

InternalOpenIDError: Failed to verify assertion #1

Open nickhall opened 5 years ago

nickhall commented 5 years ago

Reposted from https://github.com/jaredhanson/passport-openid/issues/45

I'm using this library to try and connect to an internal OpenID 2.0 authentication provider, but it fails with the following error message.

InternalOpenIDError: Failed to verify assertion
    at /Users/username/development/project/subdirectory/node_modules/@passport-next/passport-openid/lib/passport-openid/strategy.js:184:36
    at /Users/username/development/project/subdirectory/node_modules/openid/openid.js:1020:12
    at /Users/username/development/project/subdirectory/node_modules/openid/openid.js:1148:16
    at /Users/username/development/project/subdirectory/node_modules/openid/openid.js:578:13
    at /Users/username/development/project/subdirectory/node_modules/openid/openid.js:547:13
    at _parseHostMeta (/Users/username/development/project/subdirectory/node_modules/openid/openid.js:422:5)
    at /Users/username/development/project/subdirectory/node_modules/openid/openid.js:542:9
    at Request._callback (/Users/username/development/project/subdirectory/node_modules/openid/openid.js:229:7)
    at Request.self.callback (/Users/username/development/project/subdirectory/node_modules/request/request.js:185:22)
    at emitTwo (events.js:126:13)
    at Request.emit (events.js:214:7)
    at Request.<anonymous> (/Users/username/development/project/subdirectory/node_modules/request/request.js:1161:10)
    at emitOne (events.js:116:13)
    at Request.emit (events.js:211:7)
    at IncomingMessage.<anonymous> (/Users/username/development/project/subdirectory/node_modules/request/request.js:1083:12)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:111:20)
    at IncomingMessage.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1064:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

I'm attempting to access it from express with the following code:

const passport = require('passport');
const OpenIDStrategy = require('@passport-next/passport-openid').Strategy;

app.use(passport.initialize());

passport.use(
  new OpenIDStrategy(
    {
      providerURL: 'https://internal-auth-provider.domain',
      returnURL: 'http://localhost:3000/auth/openid/return',
      realm: 'http://localhost:3000'
    },
    function(identifier, done) {
      return done(null, { identifier: identifier });
    }
  )
);

app.post('/auth/openid', passport.authenticate('openid'));

app.get(
  '/auth/openid/return',
  passport.authenticate('openid', {
    failureRedirect: '/login',
    successRedirect: '/users'
  })
);

Stepping through the code with a debugger, I can see that the user data is successfully retrieved from the server, but that the list of providers comes up empty. Googling around it seems that this is a fairly common issue generally caused by version incompatibilities, but I haven't been able to pinpoint the exact cause in this case.

soorur commented 5 years ago

Any updates @nickhall @rwky ?

rwky commented 5 years ago

@soorur thanks for the ping this one must have got lost in my inbox.

An error of InternalOpenIDError: Failed to verify assertion is triggered by the openid module. The trace (thanks for that makes life much easier :+1:) points to this https://github.com/havard/node-openid/blob/master/openid.js#L1148

If you inspect the InternalOpenIDError object it should have an openidError property with the error from the openid module. A bit of googling myself found this https://github.com/jaredhanson/passport-yahoo/issues/6 (something else I need to fork by the looks of it :wink: ) I checked and we have the latest version of openid now looking at the sample code I'm guessing there's some sort of internal openid provider not a provider such as yahoo etc. which suggests it maybe either

1) A problem with the provider 2) A problem with the config 3) Something in between (a proxy/firewall) which is munging requests

Either way I don't think there's much more I can do on this one. If @nickhall can replicate this using a public provider I can try then I can debug more.