Rework security flow

[cziebuhr]

The PR addresses some issues I had when trying to use connexion for a production-ready product.

• Use token_info['sub'] instead of token_info['uid'] to better align with RFC7662 (oauth token introspection)
• x-tokenInfoUrl is only kept for compability reasons. IMHO it's only useful for a small amount of people, because it hardcodes bearer authentication (to the authorization server) and the response format is not standardized. I suggest providing an example instead, how RFC7662 can be used with a custom x-tokenInfoFunc.
• validate_token_info was not customizable and simply compared two sets of strings.
  In our setup, we want to add more logic, e.g. scope 'ressource' is superior to 'ressource:read'. One can now set a custom scope validator.
• If security definitons don't match the connexion implementation (only one definition supported), connexion silently ignors ALL definitions and allows full access to the api.
• Basic authentication / apiKey authentication had to be done manully as function decorator instead of using the security definitions from the swagger definition. Now one can define callbacks similar to x-tokenInfoFunc.
• Bonus: If both, oauth and basic auth / apiKey is specified for an operation, the new x-basicInfoFunc / x-apikeyInfoFunc also receives the required oauth scopes. This allows using oauth scopes for authorization while using basic auth / apiKey for authentication.

It's not yet fully tested and documentation/examples are not updated yet, but I would like to get some general feedback on that approach.

[dtkav]

I don't think oauth_args is in scope here.
I think you want required_scopes

[jmcs]

Thanks for the PR. Can you also include some examples of possible customizations in the documentation?

[cziebuhr]

Do you have any objectives on breaking changes?
Especially the change in FlaskRequestContextProxy. It's not really needed, but aligns better to flasks recommended approach on storing data.
What do you think about keeping/abandoning x-tokenInfoUrl?

I'm currently thinking about creating the verify_* callbacks on api level (instead of creating them for each operation). They only depend on the security_scheme, scope is passed later at call-time.

That would also fix auth_all_paths for openapi 3, which currently uses AbstractAPI.security_definitions, which is only set for swagger 2.

[jmcs]

Do you have any objectives on breaking changes?

We don't have a hard policy about breaking changes, but 2.0 already includes big backward incompatible changes, and any new breaking change will make it harder for people to migrate.

What do you think about keeping/abandoning x-tokenInfoUrl?

I would keep it with a DeprecationWarning to minimize disruption, and then we can remove it at a later time (what do you thing @hjacobs).

[cziebuhr]

Updated documentation and examples.

[jmcs]

👍

[cziebuhr]

Do you want me to squash again and also add a note about the change in flask.request?

[jmcs]

@cziebuhr That would be perfect.

[cziebuhr]

Done and updated readme.

[jmcs]

👍