Open arosenb2 opened 7 months ago
Docs specifically say here :
Unlike OAuth 2.0, you do not need to list the available scopes in securitySchemes
I guess disabling it like this is the only option to avoid this for now:
extends: ["spectral:oas"]
overrides:
- rules:
# This rule is misfiring for OIDC
# https://github.com/stoplightio/spectral/issues/2566
oas3-operation-security-defined: "off"
files:
- "**/*.yaml"
Describe the bug When using a security schema of type
openIdConnect
, scopes are being checked for being defined in the flows, but per the OpenAPI Specification, when usingopenIdConnect
,flows
is not a valid property (it should only be used with OAuth2). Therefore, the check forisScopeDefined
is invalid foropenIdConnect
.To Reproduce
openIdConnect
.oas3-operation-security-defined
triggered, listing"the-scope-you-included" must be listed among scopes.
.Expected behavior Either OIDC provided scopes should be skipped as part of the
isScopeDefined
function when the security schema is of typeopenIdConnect
. Additionally, checking forisScopeDefined
could be considered a separate rule fromoas3-operation-security-defined
so it can be selectively ignored (suggested name:oas3-operationsecurity-scopes-defined
).Environment:
Additional context OpenAPI Specification - Security Schema Object, Reference code in the ruleset