tokenUrl is not supporting relative urls

[markrzen]

Foremost, thank you so much for a fantastic set of libraries. I am filing this issue to see if you would be willing to either accept a PR on the subject.

It appears the fixed fields (e.g. clientCredentials.tokenUrl) have been modeled in this repositories schemas as AJV format uri, rather than uri-reference.

My understanding is that the AJV uri is an absolute URL, and that to have either absolute or relative, you must use uri-reference.

This results in relative urls in the tokenUrl to be required as absolute URLs, rather than allowing them to be relative (then formed into absolute using the servers object for their base).

More information about relative URLs being support unless explicitly declared invalid:
https://spec.openapis.org/oas/v3.1.1#relative-references-in-api-urls

Sorry in advance if I missed something here. I am hoping to avoid having to have multiple openapi schemas, as we have multiple environment-based oauth endpoints.

[seriousme]

Hi Mark,

thanks for asking.
It seems to be a bug in the OpenApi specification schema.
I.e. the specification says (as you correctly mention) in 4.8.29.1 that tokenUrl is a string with a note in the form of a URL .
And in 4.7.1 the specification says:

Unless specified otherwise, all fields that are URLs MAY be relative references as defined by [RFC3986] Section 4.2. Unless specified otherwise, relative references are resolved using the URLs defined in the Server Object as a Base URL. Note that these themselves MAY be relative to the referring document.

So far so good, openapi-schema-validator however does not parse the HTML to derive a JSONschema, but takes the (non-authorative) schema from the OpenApi repository to stay as close to the intentions of the OpenApi specification writers.

Unfortunately the OpenAPI specification writers have translated the URL in the HTML text to uri instead of uri-reference in their schema, e.g. see https://github.com/OAI/OpenAPI-Specification/blob/9adecc3e935f5c8a3d7bf80a7ad2202d449b9a3f/oas/3.1/schema/2024-11-14#L1278-L1281 (mind you: the gh-pages branch is the version they publish online, the main branch holds non-published draft versions!)

AJV does the right thing and treats uri as defined in section 7.3.5 of JSONschema.

So to cut a long story short: the proper place to fix this (and other) schema specification errors is in my view at the OAS Specification repository. Monkey patching these schema's in openapi-schema-validator is just not maintainable in my view.
As soon as OAS publish an update in their gh-pages branch my automation will (normally) pick it up and I will release an updated version of openapi-schema-validator.

Hope this helps.

Kind regards,
Hans

[markrzen]

@seriousme Thanks so much for the quick response. I will file an issue with OAI and see what they might have to add to the conversation. I appreciate the time you spent reviewing the issue, sorry I didn't catch that the project consumes the schema.

[seriousme]

@markrzen
I have added a note to the README to clarify: https://github.com/seriousme/openapi-schema-validator?tab=readme-ov-file#notes
Thanks again for reporting,

[seriousme]

FYI: I just released version 2.4.0 which contains the OpenAPI schema 2025-02-13 that emerged this week

[markrzen]

Thanks @seriousme!