According to the OAS 3.1 security requirement objects. BearerAuth schemes in 3.1 are allowed to use scopes on the path without using Oauth2 schema. The rule oas3-operation-security-defined is incorrectly reporting failure for 3.1.x documents.
To Reproduce
Given this OpenAPI/AsyncAPI document '
openapi: 3.1.0
info:
title: Non-oAuth Scopes example
version: 1.0.0
paths:
/users:
get:
security:
- bearerAuth:
- 'read:users'
- 'public'
components:
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: jwt
description: 'note: non-oauth scopes are not defined at the securityScheme level'
Run this CLI command '....'
spectral -r oas.default.yaml my_oas.yaml
See error
... must be listed among scopes.
Expected behavior
Given this is a 3.1 document, I wouldn't expect an error for invalid OAS formatting from OAS 3.0. The oasSecurityDefined.ts function should support a new option 3_1 that allows updated security scopes
Describe the bug
According to the OAS 3.1 security requirement objects. BearerAuth schemes in 3.1 are allowed to use scopes on the path without using Oauth2 schema. The rule oas3-operation-security-defined is incorrectly reporting failure for 3.1.x documents.
To Reproduce
spectral -r oas.default.yaml my_oas.yaml
... must be listed among scopes.
Expected behavior Given this is a 3.1 document, I wouldn't expect an error for invalid OAS formatting from OAS 3.0. The oasSecurityDefined.ts function should support a new option 3_1 that allows updated security scopes