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

Multiple values for authentication #2023

Open
GeitV opened this issue Feb 10, 2022 · 5 comments
Open

Multiple values for authentication #2023

GeitV opened this issue Feb 10, 2022 · 5 comments
Labels
enhancement New feature or request portal triaged

Comments

@GeitV
Copy link

GeitV commented Feb 10, 2022

Multiple Authentication parameters

As a web user, I'd like to do "Try It!" with authorization token and user ID, but it's not currently possible (I've checked even code of this project, and seems like this is not possibility, yet).

We are currently moving from using Postman to Stoplight. While moving, we got an issue, where we want to send Authorization: Bearer token and header X-ACCOUNT-ID: 123, as one user can have multiple accounts in our system.

Luckily, this is part of OpenAPI spec (multiple parameters by no leading dash between security parameters). However, this is not working in elements.

The ID is used as part of the authentication, so it's not really something we'd like to mark as parameter for each and every endpoint we have.

Example for this in OpenAPI

components:
  securitySchemes:
    jwtToken:
      type: http
      scheme: bearer
    accountId:
      type: apiKey
      in: header
      name: X-ACCOUNT-ID
security:
  - jwtToken: []
    accountId: []   # <-- no leading dash (-)
@mnaumanali94 mnaumanali94 added the enhancement New feature or request label Feb 17, 2022
@canvasplay
Copy link

canvasplay commented Mar 9, 2022

Having the same issue here!
This is a very common use case. Most apis require an ApiToken for any endpoint and a second BearerToken or similar for any auth endpoints.

@m-gericke
Copy link

m-gericke commented May 31, 2022

Stoplight elements currently incorrectly interprets the OpenAPI specification regarding the security requirement objects.

Security Requirement Objects that contain multiple schemes require that all schemes MUST be satisfied for a request to be authorized. This enables support for scenarios where multiple query parameters or HTTP headers are required to convey security information.

Specifically a security like this:

security:
- apiKey: []
  accessToken: []

must be interpreted as apiKey and accessToken while

security:
- apiKey: []
- accessToken: []

means apiKey or accessToken.

Currently both types are simply flattened into a single array of choices.

@manycoding
Copy link

same issue #1794

@falsaffa falsaffa added this to the Q3 '23 milestone Jul 12, 2023
@falsaffa falsaffa removed this from the Q3 '23 milestone Jul 31, 2023
@TheMrKiko
Copy link

Having the same issue!

@manycoding
Copy link

At the end, we are moving away to another product with proper support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request portal triaged
Projects
None yet
Development

No branches or pull requests

8 participants