We have PSR-18 decorators that are able to handle authentication invisibly to the application using those clients. Given those decorated clients, the generated code would not need to do anything about authentication. The checks, GET parameters, callbacks, headers and so on could all be removed, and handled exclusively in the HTTP client.
Where I am slightly in two minds, is where different endpoints on a single API may require different types of authentication, or no authentication at all. That is generally something that we would like to avoid, but the OpenAPI spec supports it, so it needs to be at least acknowledged. However, I am not sure whether the generated code (built-in PHP client) surrently supports multiple authentication types on a single API or not, so need to investigate that.
A hybrid approach could be the use of some built-in PSR-18 decorators for Basic Auth, Bear tokens, and maybe a few others, that can be automatically added to the PSR-18 client if an endpoint needs it, and if the relevant parameters have been added to the configuration. If the configuration parameters have not been set, then the package can safely assume the supplied PSR-18 client already handles the appropriate authentication.
I'm a little in two minds about how we do this.
We have PSR-18 decorators that are able to handle authentication invisibly to the application using those clients. Given those decorated clients, the generated code would not need to do anything about authentication. The checks, GET parameters, callbacks, headers and so on could all be removed, and handled exclusively in the HTTP client.
Where I am slightly in two minds, is where different endpoints on a single API may require different types of authentication, or no authentication at all. That is generally something that we would like to avoid, but the OpenAPI spec supports it, so it needs to be at least acknowledged. However, I am not sure whether the generated code (built-in PHP client) surrently supports multiple authentication types on a single API or not, so need to investigate that.
A hybrid approach could be the use of some built-in PSR-18 decorators for Basic Auth, Bear tokens, and maybe a few others, that can be automatically added to the PSR-18 client if an endpoint needs it, and if the relevant parameters have been added to the configuration. If the configuration parameters have not been set, then the package can safely assume the supplied PSR-18 client already handles the appropriate authentication.