OpenAPI 3 supports defining multiple servers for an API in a top-level servers array, and multiple security mechanisms in a security array at the top level or operation level, but doesn't appear to provide a way to specify which security requirements apply to which servers. Satisfying any security requirement is assumed to be sufficient for any server. This is problematic in cases where different servers require different authentication.
For example, consider an API with a production server and a sandbox server which each require OAuth2 to a corresponding authentication server (as in the Procore API):
openapi: 3.1.0info:
title: Server-specific Security Requirementsversion: 1.0.0servers:
- url: https://prod.example.com
- url: https://sandbox.example.comcomponents:
securitySchemes:
prodScheme:
type: oauth2flows:
implicit:
authorizationUrl: https://login.example.com/oauth/authorizescopes: {}sandboxScheme:
type: oauth2flows:
implicit:
authorizationUrl: https://login-sandbox.example.com/oauth/authorizescopes: {}security:
- prodScheme: []
- sandboxScheme: []paths: {}This implies sandboxScheme works for https://prod.example.com and prodScheme for https://sandbox.example.com, which are both unintended. Is there a way to avoid this that I've overlooked?
If not, I would suggest considering adding security to Server Object to cover this case. If this might be acceptable, I can start working on a PR or proposal.
Thanks for considering,
Kevin
P.S. This problem was mentioned in #1416 (comment) (about adding security to Path Item Objects) and the example use case in OAI/sig-security#33 (about adding support for variables in security scheme URLs). OAI/sig-security#33 is a great use case, since adding variables alone would require users to know the mapping of server variable to auth variable (e.g. sandbox.api must be used with sandbox.accounts). Adding per-Server Security Schemes could avoid the need for variables and the problem of mismatched values in that particular case.
OpenAPI 3 supports defining multiple servers for an API in a top-level
serversarray, and multiple security mechanisms in asecurityarray at the top level or operation level, but doesn't appear to provide a way to specify which security requirements apply to which servers. Satisfying any security requirement is assumed to be sufficient for any server. This is problematic in cases where different servers require different authentication.For example, consider an API with a production server and a sandbox server which each require OAuth2 to a corresponding authentication server (as in the Procore API):
This implies
sandboxSchemeworks forhttps://prod.example.comandprodSchemeforhttps://sandbox.example.com, which are both unintended. Is there a way to avoid this that I've overlooked?If not, I would suggest considering adding
securityto Server Object to cover this case. If this might be acceptable, I can start working on a PR or proposal.Thanks for considering,
Kevin
P.S. This problem was mentioned in #1416 (comment) (about adding
securityto Path Item Objects) and the example use case in OAI/sig-security#33 (about adding support for variables in security scheme URLs). OAI/sig-security#33 is a great use case, since adding variables alone would require users to know the mapping of server variable to auth variable (e.g.sandbox.apimust be used withsandbox.accounts). Adding per-Server Security Schemes could avoid the need for variables and the problem of mismatched values in that particular case.