The authorization token propagation can be used with OpenApi operations secured with a security scheme of type "oauth2" or "bearer". When configured, you can propagate the authorization tokens passed to your service and the invocations to the REST clients generated by the quarkus-openapi-generator.

Let’s see how it works by following a simple example:

Imagine that we have a updatePet operation defined in the petstore.json specification file and secured with the petstore_auth security scheme. The code below shows a simple example of the usage of this operation in a user-programmed service.

import org.acme.api.PetApi;
import org.acme.model.Pet;
import org.eclipse.microprofile.rest.client.inject.RestClient;

/**
 * User programmed service.
 */
@Path("/petstore")
public class PetResource {

  /**
   * Inject the rest client generated by the quarkus-openapi-generator.
   */
  @Inject
  @RestClient
  PetApi petApi;

  /**
   * User programmed operation.
   */
  @Path("/pet/{id}")
  @PATCH
  @Produces(MediaType.APPLICATION_JSON)
  @Consumes(MediaType.APPLICATION_JSON)
  public Response customUpdatePet(@PathParam("id") long id, PetData petData) {

    // Create a new instance of the Pet class generated by the quarkus-openapi-generator and
    // populate accordingly.
    Pet pet = new Pet();
    pet.setId(id);
    applyDataToPet(pet, petData);

    // Execute the rest call using the generated client.
    // The petstore.json open api spec stays that the "updatePet" operation is secured with the
    // security scheme "petstore_auth".
    petApi.updatePet(pet);

    // Do other required things and finally return something.
    return Response.ok().build();
  }

  public static class PetData {
    // Represents the Pet modifiable data sent to the user programmed service.
  }

  private void applyDataToPet(Pet pet, PetData petData) {
    // Set the corresponding values to the Pet instance.
  }
}

Let’s see what happens when the PetResource service customUpdatePet operation is invoked by a third party.

Default flow

  1. The customUpdatePet operation is invoked.

  2. An authorization token is obtained using the corresponding petstore_auth OidcClient configuration. (for more information see [_oauth2_authentication])

  3. The authorization token is automatically passed along the PetApi updatePet operation execution using an automatically generated request filter, etc.

Propagation flow

However, there are scenarios where we want to propagate the authorization token that was initially passed to the PetResource service when the customUpdatePet operation was invoked instead of having to obtain it by using the OidcClient.

  1. The user service customUpdatePet operation is invoked, and an authorization token is passed by the third party typically by using the HTTP Authorization header.

  2. The incoming authorization token is automatically passed along the PetApi updatePet operation execution according to the user-provided configuration.

When configured, the token propagation applies to all the operations secured with the same securityScheme in the same specification file.

Propagation flow configuration

The token propagation can be used with type "oauth2" or "bearer" security schemes. Finally, considering that a given security scheme might be configured on a set of operations in the same specification file when configured, it’ll apply to all these operations.

Property Key Example

quarkus.openapi-generator.[filename].auth.[security_scheme_name].token-propagation=[true,false]

quarkus.openapi-generator.petstore_json.auth.petstore_auth.token-propagation=true
Enables the token propagation for all the operations that are secured with the petstore_auth scheme in the petstore_json file.

quarkus.openapi-generator.[filename].auth.[security_scheme_name].header-name=[http_header_name]

quarkus.openapi-generator.petstore_json.auth.petstore_auth.header-name=MyHeaderName
Says that the authorization token to propagate will be read from the HTTP header MyHeaderName instead of the standard HTTP Authorization header.