[BUG] [JAVA] client enforces unsupported authentication methods to exist

Bug Report Checklist

• [✅] Have you provided a full/minimal spec to reproduce the issue?
• [✅] Have you validated the input using an OpenAPI validator (example)?
• [✅] Have you tested with the latest master to confirm the issue still exists?
• [✅] Have you searched for related issues/PRs?
• [✅] What's the actual output vs expected output?
• [🚧] [Optional] Sponsorship to speed up the bug fix or feature request (example)
  ☝️ I'm trying to get my company to contribute back in some way to foss, still a WIP though 😞

Description

Hi there! I'm trying to generate a client for the Twitter V2 API using their openapi spec , but when I try to make a request it tosses an error saying an authentication (UserToken) is undefined. I've tried to dig in and find exactly where that isn't getting defined, but this is all new to me so I may have missed something.

Check out the spec - it defines an oauth (1) security schema under the UserToken key, which most endpoints are defined have support for. It also defines a bearer and oauth2 security scheme, which are making it into the generated client.

Digging through the code, it looks like Oauth 1 is not supported in SecurityFeature.java - it doesn't have a definition for OAuth 1, only 2. Consequently, in AbstractJavaCodegen.java it doesn't exist to be added to the list of (what I suppose are) the supported security schemes for the language.

I looked around and as far as I can tell there's no way to 'work around' this problem with the generated Java code. You would need to change the openapi spec to remove the declarations. I can do that to get past this problem for now, but I automated creating the client so would much prefer not to. Again, I might have missed something - please let me know if I got anything wrong.

openapi-generator version

I'm using the v1 of the github action openapi-generators/openapitools-generator-action@v1 - I looked through there but I couldn't figure out which version that was using.
I also ran this locally using 7.2.0 and building from the main branch

OpenAPI declaration file content or url

https://api.twitter.com/2/openapi.json

Generation Details

openapi-generator generate -g java -i <input_file> -o target

Steps to reproduce

1. Using twitter's openapi spec, generate a client

2. Set up the API client. I'm setting the OAuth2 values, but each constructor looks to set it in some way so it doesn't throw the undefined error.

   ApiClient API_CLIENT = new ApiClient(TWITTER_V2_BASE_URL, CLIENT_ID, CLIENT_SECRET, PARAMETERS);

3. Attempt to make a request (i.e., blocked users)

   Get2UsersIdBlockingResponse blockedUsersResponse = new UsersApi(API_CLIENT).usersIdBlocking(
    TWITTER_ACCOUNT_ID,
    50,
    "",
    null,
    null,
    null
   );
   

4. Error is thrown!

   Caused by: java.lang.RuntimeException: Authentication undefined: UserToken

Related issues/PRs

I tried searching for something related to oauth but I couldn't find anything necessarily covering this issue.

Suggest a fix

Oauth1 is not supported, but that's not the bug to be fixed here. Theoretically, any security schemes could be defined on the endpoints, supported or not.

In the code, there's a localVarAuthNames variable that holds which authentications to pick up and try. If a security scheme is not supported (and so not is not generated into the client), endpoints that define that security scheme shouldn't generate that security scheme into that list of authentications to use.

I don't know yet exactly where the variable is generated, but I'll take a look and try and dig in and get some more specific thoughts on implementation.

Start with SecurityFeature.java and AbstractJavaCodegen.java, then trace how localVarAuthNames is generated for Java clients. Reproduce with the Twitter V2 OpenAPI specification and the blocked-users request described in the issue. Done means endpoints no longer attempt unsupported security schemes and the generated client no longer throws "Authentication undefined: UserToken".