Openapi-generator: [Java] support for bearer authentication

[lorenzleutgeb]

Please see swagger-api/swagger-codegen-generators#113

The output that OpenAPI generator 020883fd4da67050a6ae1b228daa8cef6849d732 produces suffers from the same defect. However I did not look into your codebase. I understand that referring to the Swagger Codegen project might not be the most sensible thing to do, and if you rather do not want to look at it, I could look for the cause in this codebase.

[jmini]

Welcome here!

Thank you for this issue.

_There is no problem to mention Swagger-Codegen. The codebase are similar, Swagger-Codegen v3 and OpenAPI-Generator are both evolutions of Swagger-Codegen 2.x.
My personal summary of the story is that the opinions about next steps went apart..._

---

You have located the correct section in the template. In this code base it is here:
https://github.com/OpenAPITools/openapi-generator/blob/020883fd4da67050a6ae1b228daa8cef6849d732/modules/openapi-generator/src/main/resources/Java/ApiClient.mustache#L103-L106

My take is that there is no support for bearer yet. Is this a new feature of OpenAPI 3?

---

Could you please post in this issue a full OAS3 example, you can adapt the very ping.yaml example, where you put the values for bearer as they should be for your case.

From your post I understood that you generate a java client, but can you post the command you are using (cli, maven, gradle or java integration of the core)? The base library you are using is the important point...

[lorenzleutgeb]

From your post I understood that you generate a java client, but can you post the command you are using (cli, maven, gradle or java integration of the core)?

I cloned/checked out 020883fd4da67050a6ae1b228daa8cef6849d732 and ran mvn clean package. With the resulting JAR I do

java -jar openapi-generator-cli.jar generate -l java -i api.yml -o jclient

I do not understand why you categorized this to affect the Java compilation target specifically. From my limited understanding of the codebase here, it seems that the error is actually in the frontend, i.e. in the shared Java code that underpins generation and the issue therefore affects all targets. In the issue for the Swagger implementation I mention that I think the error is in their io.swagger.codegen.languages.DefaultCodegen class (lines highlighted) which translates to your org.openapitools.codegen.DefaultCodegen (lines highlighted) in straight forward ways. In the OpenAPI Tools codebase, the assumption that HTTP authentication implies HTTP authentication using the basic authentication scheme is valid just like in the Swagger codebase, so the root causes align.

Could you please post in this issue a full OAS3 example, you can adapt the very ping.yaml example, where you put the values for bearer as they should be for your case.

openapi: 3.0.1
info:
  title: ping test
  version: '1.0'
servers:
  - url: 'http://localhost:8000/'
paths:
  /ping:
    get:
      operationId: pingGet
      responses:
        '201':
          description: OK

# Modifications are below this line. Above is ping.yaml.

components:
  securitySchemes:
    bearer:
      type: http
      scheme: bearer

security:
  - bearer: []

[jmini]

You are right, I did not investigate it yet, but one part of the fix will be in the Codegen-layer (OAS3-Feature label) and the java template needs to be adjusted too.

Or I have missed something and I will be happy to change that.

[lorenzleutgeb]

I see. Thanks.

[chrisesharp]

+1 on this. I came across exactly the same issue this week trying to generate a client with a Bearer JWT token:

securitySchemes:
    JWT_auth:
      type: http
      description: JWT authentication needed
      scheme: bearer
      bearerFormat: JWT

[jason-cohen]

@jmini has there been any further development into this issue?

Like you pointed out, it's not exactly an issue with the mustache templates. It primarily arises from the DefaultGenerator assuming HTTP security type implies BASIC Auth, without any further investigation as to the scheme provided.

A simple minimal solution might be to replace (DefaultCodegen.java line 2953):

} else if (SecurityScheme.Type.HTTP.equals(securityScheme.getType())) {
    cs.isKeyInHeader = cs.isKeyInQuery = cs.isKeyInCookie = cs.isApiKey = cs.isOAuth = false;
    cs.isBasic = true;
}

with

} else if (SecurityScheme.Type.HTTP.equals(securityScheme.getType())) {
    cs.isKeyInHeader = cs.isKeyInQuery = cs.isKeyInCookie = cs.isApiKey = cs.isBasic = cs.isOAuth = false;
    if ("basic".equals(securityScheme.getScheme())) cs.isBasic = true;
    if ("bearer".equals(securityScheme.getScheme())) cs.isOAuth = true;
}

However I haven't investigated as to the implications of having isOAuth true without the other oauth fields set.

[lorenzleutgeb]

@jason-cohen Just hijacking the OAuth security scheme is a bad idea. For example, the spec requires an OAuth flow to be set on security schemes of this type, which is something that cannot be inferred (and might even not apply) in the case of a different HTTP authentication scheme. What you suggest as a solution here is a workaround that will immediately fail as soon as someone wants to use a different scheme than Bearer... I strongly urge @jmini to not further follow this proposal.

[jason-cohen]

@lorenzleutgeb Very good point. I agree, hijacking the OAuth scheme is a bad idea as it couples them, when the very point of the http-bearer scheme was to have an authorization bearer header not coupled with OAuth.

Maybe a more viable option would be to add a new field isBearer that could be used in the templates in a manner similar to the isBasic.

[davidwcarlson]

I am running into the same issue with BearerAuth. It looks like the recent commit 80ca67cf took care of the changes to DefaultGenerator to correctly set the existing BasicBasic and BasicBearer variables.

In response to @jason-cohen's concerns about highjacking OAuth, my pull request https://github.com/OpenAPITools/openapi-generator/pull/1930 adds a new BearerAuth object and uses it if the BasicBearer is set to true.

[wing328]

https://github.com/OpenAPITools/openapi-generator/pull/1972 by @davidwcarlson has been merged into master. Please give it a try with the latest master.