Confusing message when authenticator result type is `invalid` about exegesis

[jwalton]

Yes, although I'd suggest if there's at least one set of invalid credentials, we should still fail, even if there's also some valid passing credentials. I'm working on something - hopefully I'll have a fix for this after the weekend.

[jwalton]

This is confusing.

So, let's say you have an operation that has a security requirement like:

{
    "sessionKey": [],
    "basicAuth": []
}

Now, if someone authenticates with a good sessionKey, we're never going to even try to authenticate against basicAuth. If someone authenticates with a bad sessionKey, though, should we continue on to try basicAuth, or should we reject immediately? What if they have good basicAuth credentials and a bad sessionKey?

It's tempting to say we should reject immediately, but then, if you have a good basicAuth and a bad sessionKey and you get this security requirement:

{
    "basicAuth": [],
    "sessionKey": []
}

where basicAuth and sessionKey are reversed, then we'd accept this (since we'd pass the basicAuth, and never bother to check the sessionKey). It's kind of weird that we pass in the one case, and fail in the other, just because the order of security requirements is different.

Maybe what we should really be doing here is not short-circuiting on success - always run all the authenticators, and if any of them returns "invalid" we fail. The only real downside to that is that exegesis-passport usually doesn't know the difference between a missing result and an invalid result, but so long as it errors on the side of "missing" it's not any worse than what we have now.

[niallmccullagh]

I think the invalid credentials scenario is going to be more common with the scenario of multiple "credentials" being an edge case. The multiple credentials being passed would be also easier to spot from the request.

It's tempting to say we should reject immediately, but then, if you have a good basicAuth and a bad sessionKey ... It's kind of weird that we pass in the one case, and fail in the other, just because the order of security requirements is different

That a very good point. Could this flow be a possible solution?

For each authenticator

1. check the security requirement
2. collect in array if invalid
3. return on the first success
4. If there was no successful result but one or more invalid results then return an error listing the schemes(s) that were invalid {message: "Authentication was invalid for the the following schemes: sessionKey." errors: [{scheme: result[x].failedSchemeName, message: result[x].message, ... }] with the detailed messages of the invalid results }
5. If all are missing then return { "message":"Must authenticate using one of the following schemes: sessionKey." }
   Obviously setting the headers appropriately.

I think the consumer of the API would have a clear understanding what occurred. An update to the developer documentation would be needed to call out that the order that the authenticators are run in and that the process is short-circuited on a success.

Maybe what we should really be doing here is not short-circuiting on success - always run all the authenticators, and if any of them returns "invalid" we fail. The only real downside to that is that exegesis-passport usually doesn't know the difference between a missing result and an invalid result, but so long as it errors on the side of "missing" it's not any worse than what we have now.

Agreed. The passport flow would be no worse than the current flow, but things would be improved for other integrations.

[niallmccullagh]

Hi Jason,

Some interesting documentation in the specification under Using Multiple Authentication Types ...

Some REST APIs support several authentication types. The security section lets you combine the security requirements using logical OR and AND to achieve the desired result.

OR case

    security:    # A OR B
      - A
      - B

• Successfully authenticate if either A or B returns a success.
• A 'invalid' or 'missing' result in only one will be ignored.

AND case

    security:    # A AND B
      - A
        B

• Successfully authenticate only if both A or B returns a success.
• A 'invalid' or 'missing' result in either will cause authentication to fail.

It makes sense to follow the spec but I can see that it wouldn't be a small change. It would also have an impact on the authenticator results, as they would need merged together when there is multiple results.

[jwalton]

🎉 This issue has been resolved in version 1.0.7 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀