Separation of concerns: Auth

[handrews]

We've identified a "separation of concerns" philosophy for Moonwalk. How might this extend to authentication?

As a concrete use case, people have requested OAuth 1.0 support as recently as October, 2023. I am very, very, very far from an OAuth expert, but my understanding is that the complexity of OAuth 2.0 has kept some folks on 1.0, in addition to the usual legacy inertia. Past discussions on this (OAI/OpenAPI-Specification#61 (comment)) have concluded that it's complicated and more likely to cause problems for tooling support than solve them.

Would it be possible in Moonwalk to modularize auth (not specifically OAuth) support to make it easier to define additional auth approaches for either legacy or bleeding-edge approaches? I am envisioning something a bit more encouraging than simply "try some extension keywords". More along the lines of defining what a representation of an authentication approach needs to do so that 3rd parties can define how to add them to Moonwalk without needing to resort to weird hacks, or violating Moonwalk's design principles.

[handrews]

I think a key factor here would be defining this in a way that tooling vendors would support some sort of plug-in interface. The core OAS and its implementation requirements need to avoid complex use cases with relatively few users. But these use cases can be important to large enterprises with legacy management requirements who might fund an effort on the scale of a plug-in.

[SensibleWood]

There's a salient example in the v3.1 specification, namely OpenID Connect, that I think points to how the design approach could play out.

In the current specification the guts of OpenID Connect support is an indicator saying "this API/Operation supports OpenID Connect for authentication" and a pointer to a discovery endpoint in openIdConnectUrl. The discovery endpoint contains data that is well-described, informative and machine-readable. This loose-coupling allows OpenAPI to say "its over here chaps" and then OpenID Discovery to then take over. For tooling makers this is nice because their OpenID Discovery tools don't need to understand OpenAPI much - they just need to understand a link to it.

If this style can be replicated and enhanced for Moonwalk that is a good thing IMO. Obviously there's a restriction where there's no decent protocol governing the authentication mechanism, but perhaps those blanks could be dealt with on a case-by-case basis.

[garymazz]

The loose coupling disconnects auth mechanisms from resources and operations which made increase compliance and real world interoperability more challenging for implementers. For example, oAuth scope information defines a resources and the contract applied. Decoupling provides implementers with flexibility. Conversely, clients will be burdened with cross-implementation scope terms reconciliation.