Add API-key scope checking

[etvahala]

Fixes # N/A

The current documentation mentions that API-key
security supports scopes: "
The function should accept the following arguments:

• apikey
• required_scopes (optional) "

However, the scopes were not passed to the checker.

Changes proposed in this pull request:

• Add missing parameter routing to ApiKeySecurityHandler
• Add a unit test for API-key scopes

[RobbeSneyders]

Thanks @etvahala!

2 points:

• The openapi docs only describes scopes for oauth2 and OpenID security schemes, and mentions the scopes are empty for all other schemes. API Key authentication should allow scopes to be defined. OAI/OpenAPI-Specification#1366 seems to mention that this was changed in the 3.1 spec, however I don't see this included in the actual spec.
  Adding scopes to an API key security block does seem to pass validation for 3.X specs, but not for 2.X specs. So I'm not sure if we should add support for this.
  @etvahala could you post the relevant parts of your spec to show how you define this?
  @Ruwann what do you think?

• The tests are failing. You can wait until we have decided about point 1, although I would be more inclined to support this if you can show that it can pass the test suite without introducing a lot of complexity to maintain.

[RobbeSneyders]

Ping @etvahala @Ruwann

[etvahala]

Fixed the unit tests.

The scope support for API keys was introduced in this OpenAPI spec commit, by introducing weasel words "...and the list MAY be empty if authorization does not require a specified scope.".

[RobbeSneyders]

Thanks @etvahala!

I don't think the line you linked is relevant, but the next one is:

For other security scheme types, the array MAY contain a list of role names which are required for the execution, but are not otherwise defined or exchanged in-band.

See also this OpenAPI issue.

So seems to align with the spec indeed 👍

[coveralls]

coverage: 94.214%. remained the same
when pulling 7105ed9 on etvahala:feature/apikey-scopes-support
into 211bdb0 on spec-first:main.

[RobbeSneyders]

Thanks, one small suggestion.

[Ruwann]

Thanks! The current implementation looks good to me.
I believe we should also extend it to other security schemes, not only API keys?

For full reference, in the past, connexion re-used the scopes value from other security schemes as required_scopes as argument value security schemes that didn't allow scopes. This was addressed in PR #1474

[evahala]

Can somebody merge this in?