Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple required security schemes #16

Open
adlerfaulkner opened this issue Jun 19, 2023 · 0 comments
Open

Support multiple required security schemes #16

adlerfaulkner opened this issue Jun 19, 2023 · 0 comments

Comments

@adlerfaulkner
Copy link
Member

adlerfaulkner commented Jun 19, 2023

Currently this library only uses the first key of a security requirement object as the required security scheme. We should support all security schemes listed in a security requirement.

For example, an OpenAPI operation may have a security requirement of:

{
    "clientAuth": [],
    "userToken": []
}

Which corresponds to security schemes in such as:

{
    "components": {
        "securitySchemes": {
            "clientAuth": {
                "type": "http",
                "scheme": "bearer",
                "bearerFormat": "JWT",
                "description": "JWT to authenticate the client"
            },
            "userToken": {
                "type": "apiKey",
                "name": "X-Authorization-User",
                "in": "header",
                "description": "API key to authenticate users"
            }
        }
    }
}

Note: to support multiple schemes or type apiKey in one operation, the configuration argument should accept the api keys by their name rather than just apiKey. The apiKey field can be used as a backup if the name of the api key is not supplied. The same should NOT be true for security schemes of type http or oauth2 because they use a specific header format and support for multiple values are not defined in their specs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant