Pluggable Auth policy follow up items

[achamayou]

• Listing these auth policies in OpenAPI. I've sketched the correct type of JSON objects, but not added them yet. A slight annoyance here is it looks like there's not a way to describe our 'cert auth' policy in OpenAPI? If anyone can see a better solution than "don't mention it in the OpenAPI", please let me know. (Document auth policies in OpenAPI #2049)
• Exposing these auth policies through js_generic by name (in app.json and the user object). On the C++ side I've opted entirely for type-based comparisons, but since we need unique names for JS we should see if it makes sense to use these in C++ as well.
• A test demonstrating a custom policy. (Add example of custom auth policy, and documentation of new auth types #2050)
• installing endpoints without any policy should give a clear error, as early as possible, to avoid accidentally unauthenticated enpoints. Endpoints that deliberately want no authentication should set empty_auth_policy. (Set auth policies at construction #2048)

[lynshi]

Regarding your first point, we have come across the same thing - OpenAPI doesn't support cert-based auth. However, the feature request for it has been open for a while, and it looks like a mutualTLS option has made it into 3.1: OAI/OpenAPI-Specification#1764.

[achamayou]

@lynshi what’s your view on CCF using OpenAPI 3.1 as soon as it is released?

[lynshi]

I think that's fine. Using the latest specification can't hurt for readability/maintenance going forward.

We have to write our own Swagger anyway to submit to the Azure REST API specs repo, which basically decouples us from CCF for anything documentation related.