SessionStrategy does not reject requests when no authenticated session has been established

[vamship]

I have passport setup for a web app with the local strategy for authentication, and passport.session() (the session strategy) to authenticate all subsequent requests (once an authenticated session has been setup). This works great if a user goes to the login page, and then navigates to a page that uses the session strategy.

The issue that I noticed was that the SessionStrategy does not reject the request if no session is present at all. Specifically, this line of code bypasses all further checks if a user object does not exist in session. I can get around this issue by using another middleware to explicitly check if the user restored by the session is valid, but I feel it would be much cleaner if the session middleware did this automatically.

Have I understood the motivation behind the design of this strategy incorrectly?

[sstadelman]

I have exactly the same question. I think it is this strategy.pass = function() {next();} which causes the strategy to "Pass without making a success or fail decision."

I can handle the user verification in each route, but I had hoped that it would be encapsulated in the session verification.

[vamship]

Actually, you're right. I did get the line number wrong. But the issue is fundamentally the same - passport is treating the absence of a session token as if the user was successfully authenticated. That could potentially leave an implementation exposed with security vulnerabilities if the developer is not careful to handle this case.

[juona]

Quite surprised to find out that this particular question was asked so long ago and that it never gained any traction.

Admittedly, the confusion between authentication and authorization hasn't gone anywhere, and Passport seems to successfully contribute to this by making the built-in session strategy authentication-only, whilst enough other strategies also reject unauthorized requests, thus implementing authorization too ("unauthenticated clients are not granted access" is an authorization policy).

I would argue that in some cases this behavior might make sense - e.g. if a resource is public but has additional logic if the client is authenticated.

Personally I find the lack of consistency to be the biggest issue - it took me a while to figure out why things behaved the way they did. Adding an additional req.isAuthenticated() check is easy enough, but it warrants a comment because it is definitely not intuitive.

Also, a few additional comments were added to the session strategy code, which explain the reasoning: https://github.com/jaredhanson/passport/blob/master/lib/strategies/session.js#L71