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

Add security to the components object #1850

Closed
djpadz opened this issue Feb 27, 2019 · 5 comments
Closed

Add security to the components object #1850

djpadz opened this issue Feb 27, 2019 · 5 comments
Labels
re-use: ref-everywhere Requests to support referencing in more / all places security: config The mechanics of severs and structure of security-related objects security

Comments

@djpadz
Copy link

djpadz commented Feb 27, 2019

Consider this snippet:

components:
  securitySchemes:
    jwt:
      type: apiKey
      in: cookie
      name: JWT_TOKEN
    apiToken:
      type: http
      scheme: bearer
    httpBasic:
      type: http
      scheme: basic

If I want a set of requests to support each of these authentication methods in turn, I would have to add something like:

    security:
    - jwt: []
    - apiToken: []
    - httpBasic: []

...to each one. It would be far easier if the components object supported a security section, something like this:

components:
  security:
    myAuths:
    - jwt: []
    - apiToken: []
    - httpBasic: []

...so that requests could just include:

    security:
      $ref: '#/components/security/myAuths'
@darrelmiller
Copy link
Member

You could define the security constraints in the root object and then override it on a per operation basis where necessary.

@djpadz
Copy link
Author

djpadz commented Feb 28, 2019

True, but the components object includes most of the other bits. Might as well include security.

@darrelmiller
Copy link
Member

@djpadz Yes, but most other components don't have top level objects that apply globally. Having an API where the security schemes vary significantly across the API doesn't seem like desirable behavior. Having an anonymous API with some specific operation auth'd seems normal, or the opposite where it is secured but with some anonymous exceptions seems normal.

Can you tell us more about your use case where you want to vary the types of auth allowed across your API? Our concern is about adding unnecessary complexity.

@djpadz
Copy link
Author

djpadz commented Feb 28, 2019

In my particular use case, adding the security definition to the top level would work. The thought was more about allowing components to include anything that would go into a request, as opposed to selected things.

@handrews handrews added security $ref re-use: ref-everywhere Requests to support referencing in more / all places security: auth Authentication including overlap with authorization security: config The mechanics of severs and structure of security-related objects and removed $ref security: auth Authentication including overlap with authorization labels Jan 28, 2024
@handrews
Copy link
Member

Consolidating under #3853 and closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
re-use: ref-everywhere Requests to support referencing in more / all places security: config The mechanics of severs and structure of security-related objects security
Projects
None yet
Development

No branches or pull requests

3 participants