spec-first
Make security pluggable by authentication type
It would be great to refactor the security middleware to be pluggable by authentication type. The goal would be to be able to register a handler, a class or function with an interface we define, to check certain security schemes.
This way people can still use unsuported authentication types (eg. #694), and possibly contribute it back to connexion.
I like the way Starlette handles this in their AuthentictionMiddleware:
https://github.com/encode/starlette/blob/master/starlette/middleware/authentication.py
https://github.com/encode/starlette/blob/master/starlette/authentication.py
https://www.starlette.io/authentication/
I think it's worth investigating whether we can base the connexion security middleware on this.
This would be very helpful, plus 1 from me also. There is also another scenario we would like to have: be able to add on the same application 2 different API Specs with completely different security schemes defined in the spec. For example we could have an end-user API and an administration API which should be able to use completely different authentication logic.
