Automatic Request / Response Authentication

I raised a similar issue on GitHub yesterday, but this is more fundamental and so merits a larger discussion.

Fundamentally, what is the intended implementation of request / response authorization in Vapor? This would include Basic and Digest auth, as well more esoteric authentication like Kerberos (I think). As far as I can tell, the current BasicAuthenticator doesn't implement this pattern, leaving it to the route to perform the proper response. This doesn't seem correct, and in attempting to implement Digest auth I've found it's not adequate for stateful request / response authorization. All of the documentation I've seen seems to assume requests made with all the proper credentials and no necessary response -> request -> response chain. Am I missing something?

BasicAuthenticator is pretty simple. All it does is check the Authorization: Basic header. If there are credentials there, it tries to authenticate them. Otherwise, it does nothing.

Adding support for the WWW-Authenticate header and response -> request -> response chain as you mention seems like a good idea though.

Maybe it would make sense to add this as a separate middleware or to GuardMiddleware? The idea with authenticators is that they should silently fail if the credentials they are looking for are missing. This allows you to chain multiple authenticators for different credential types together. For example, a route could be protected by both Authorization: Basic and Authorization: Bearer. You can add GuardMiddleware after one or more authenticators to ensure that at least one of them was successful. Doing req.auth.require(User.self) in a route achieves the same thing.

More information on how other server frameworks handle the WWW-Authenticate header would also be helpful for making a decision.

Sounds good. I'll experiment with other Middlewares to see how they interact. Would a DigestAuthenticator be something Vapor wants? It's not really recommended for use, but neither is Basic auth. I just need it to test Alamofire's / URLSession's Digest handling.

Potentially. I'm not too familiar with how that works to say myself, but if you give good reasoning for it to be included then I don't see why not. Pointing to other web frameworks that include similar functionality is the strongest argument.