swagger-api / validator-badge

Validate your Swagger JSON/YAML today!
http://swagger.io
Apache License 2.0
210 stars 85 forks source link

securitySchemes failing validation with certain fields #200

Closed nicholi closed 5 months ago

nicholi commented 2 years ago

Sample OAS 3.0 yaml tested with https://validator.swagger.io/validator/debug?url=

openapi: 3.0.0
info:
  title: Bearer auth test
  version: 1.0.0
servers:
  - url: https://httpbin.org
paths:
  /get:
    get:
      responses:
        '200':
          description: ok
security:
  - bearerAuth: []
components:
  securitySchemes:
    bearerAuth:
      type: http
      name: Authorization
      in: header
      scheme: bearer

It seems as soon as the name or in properties are specified in the security scheme object, validation fails. Output:

{
  "schemaValidationMessages": [
    {
      "level": "error",
      "domain": "validation",
      "keyword": "oneOf",
      "message": "instance failed to match exactly one schema (matched 0 out of 2)",
      "schema": {
        "loadingURI": "#",
        "pointer": "/definitions/Components/properties/securitySchemes/patternProperties/^[a-zA-Z0-9\\.\\-_]+$"
      },
      "instance": {
        "pointer": "/components/securitySchemes/bearerAuth"
      }
    }
  ]
}

From the OpenAPI 3.0 spec these definitely shouldn't cause validation errors, and from the spec at least they are assumed to be REQUIRED. https://swagger.io/specification/#security-scheme-object Is there something I am missing in defining the scuritySchemes object?

nicholi commented 2 years ago

I think I already found the answer examining the schema format you validate against: https://github.com/swagger-api/validator-badge/blob/master/src/main/resources/schema3-fix-format-uri-reference.json

If type: http is chosen the fields in and name cannot be used because they will confuse the schema validator about what type of securitySchema object is being referenced. My intention was to use HTTPSecurityScheme. Simplest answer seems to be do not specify in: header and name: Authorization. These would be implied anyways under the HTTP scheme, I just did not think explicitly specifying them would cause problems.