OpenID Connect 1.0 Support

[jessechahal]

Description

I am trying to generate a java client jar of my openapi 3.0.0 yaml document. I noticed that the end client library does not have support for openID Connect 1.0. OpenAPI 3.0.0 is supposed to support this authenication scheme. Right now I do not see much different between using this codegen tool vs the one swagger provides for swagger1.5 codegen (other then you guys got the build.gradle file right).

openapi-generator version

homebrew java

OpenAPI declaration file content or url

openapi: 3.0.0
servers:
  - url: http://localhost:2020
  - url: http://localhost:8080
  - url: /candy
info:
  description: This service provides APIs to eat chocolate.
  version: 0.0.1
  title: chocolate Service
tags:
  - name: chocolates
components:
  securitySchemes:
    openId:   
      type: openIdConnect
      openIdConnectUrl: /auth/realms/master/.well-known/openid-configuration
security:
  - openId:  
    - openid
paths:
  /candy:
    post:
      tags:
        - chocolates

Command line used for generation

Exact command I ran was openapi-generator generate -i openapi_3.yml -g java -o openapi_3_java Looking at the generated files there does seem to be support for oauth2 but no support for openIDConnect in the .auth package.

Steps to reproduce

• run the openapi code generator on a yaml/json file that follows openapi 3.0.0 spec. The Yaml file should specify openID connect authentication scheme.

Related issues/PRs

no, did a search and nothing came up.

Suggest a fix/enhancement

Goal should be to add openID connect support to match the openapi 3.0.0 spec.

[wing328]

@jessechahal thanks for the details. May I know if you've time to contribute the support of OpenID in the Java client? I can show you some good starting points.

[fuzzzerd]

Is this something that needs updated within the Java code for OpenAPI Generator and then the mustache templates, or does this only need implemented in the templates?

[Guschtel]

@wing328 could you write down your pointers here?

[trickert76]

I'm suprised that the OpenAPI v3 specification isn't completly usable with the latest OpenApi generator. According to the v3 spec - the type "openIdConnect" is valid - but OpenApi generator ignores it completely (swagger-ui too, but that is another issue). Nearly two years after the issue was open - nobody is working on it.

When I have a look at the code - OIDC is complete not available. See https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L3852 and just for example https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/Java/libraries/resttemplate/ApiClient.mustache#L128 there is no OIDC "switch".

So - this is a base point to start - I'm not sure, if the underlying parser already knows OIDC. The necessary io.swagger.v3.oas.models.security.SecurityScheme already knows the type OPENIDCONNECT.

[trickert76]

Because for me it's to much to change I made a workaround in case of Java/Resttemplate and KeycloakRestTemplate I copied the mustache templates of java/resttemplate and added a dummy entry to the private authentication Map and injected the KeycloakRestTemplate. Because the KeycloakRestTemplate already knows the session specific OIDC Tokens etc, I only needed to inject it.

My dirty workaround for Java/RestTemplate with KeycloakRestTemplate

public class UglyApiClient extends ApiClient {
  public UglyApiClient(KeycloakRestTemplate restTemplate) {
    super(restTemplate);
    addAuthentication("oidc", new HttpBearerAuth(null));
  }
}

And the ApiClient.mustache

-  // Prevent the authentications from being modified.
-  authentications = Collections.unmodifiableMap(authentications);

+ public void addAuthentication(String authName, Authentication auth) {
+     authentications.put(authName, auth);
+ }

And the pom.xml

  <plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>4.3.0</version>
    <executions>
      <execution>
        <goals>
          <goal>generate</goal>
        </goals>
        <configuration>
          <inputSpec>${project.basedir}/mybackend-api-v${mybackend-version}.json</inputSpec>
          <generatorName>java</generatorName>
          <library>resttemplate</library>
          <templateDirectory>${project.basedir}/openapi-templates/java</templateDirectory>
          <generateApiTests>false</generateApiTests>
          <generateApiDocumentation>false</generateApiDocumentation>
          <generateModelTests>false</generateModelTests>
          <generateModelDocumentation>false</generateModelDocumentation>
          <configOptions>
            <sourceFolder>src/gen/java</sourceFolder>
            <useBeanValidation>true</useBeanValidation>
            <dateLibrary>java8</dateLibrary>
          </configOptions>
          <apiPackage>myclient.frontend.generated.client.api</apiPackage>
          <modelPackage>myclient.frontend.generated.client.model</modelPackage>
          <invokerPackage>myclient.frontend.generated.client</invokerPackage>
        </configuration>
      </execution>
    </executions>
  </plugin>

[Guschtel]

If you are using Spring, your can extend the Templates to inject a RequestInterceptor. I've done it and can provide a patch/ code examples in the next few days, if interested. I've implemented the changes for both okhttp-gson and feign types to get a spring boot app (actually jhipster) to work with an openapi generated mvn library.

Then you can simply use any kind of RequestInterceptor, i.e. a FeignRequestInterceptor, etc.

[Yuutakasan]

@Guschtel I was looking for a reference implementation in Spring. I am interested.

[languitar]

Does anyone know a quick workaround to get security annotations into jaxrs-spec with the Qarkus library?

[jtama]

Hi, I've put up a start to enable OIDC support. It only makes OIDC scheme security and operation securities requirements for DefaultCodegen and DefaultGenerator.

[FabianWilms]

Are there any plans to support OpenID Connect in the future? This issue is close to 6 years old.

We're currently forced to manually strip all security schemes with openidconnect from our api-docs in order to use the generator.