Support configuration per oauth2 flow

Content & configuration

Swagger/OpenAPI definition:
Take https://petstore.swagger.io/v2/swagger.json as the base definition, with the following security definitions (renamed the existing implicit definition and added three more oauth2 definitions):

   "securityDefinitions": {
       "api_key": {
           "type": "apiKey",
           "name": "api_key",
           "in": "header"
       },
       "petstore_auth": {
           "type": "oauth2",
           "authorizationUrl": "https://petstore.swagger.io/oauth/authorize",
           "flow": "implicit",
           "scopes": {
               "read:pets": "read your pets",
               "write:pets": "modify pets in your account"
           }
       },
       "petstore_auth_client_credentials": {
           "type": "oauth2",
           "authorizationUrl": "https://petstore.swagger.io/oauth/authorize",
           "flow": "client_credentials",
           "scopes": {
               "read:pets": "read your pets",
               "write:pets": "modify pets in your account"
           }
       },
       "petstore_auth_password": {
           "type": "oauth2",
           "authorizationUrl": "https://petstore.swagger.io/oauth/authorize",
           "flow": "password",
           "scopes": {
               "read:pets": "read your pets",
               "write:pets": "modify pets in your account"
           }
       }
   },

Swagger-UI configuration options:
https://github.com/swagger-api/swagger-ui/blob/2e523e1fccd569678414a62d50ebe7b2dffa6626/dev-helpers/dev-helper-initializer.js#L22-L32

Is your feature request related to a problem?

Given the above OpenAPI spec, the initOAuth parameters may not work for a scenario where different flows require different client_id.

For instance, when configuring an application in Auth0, one can choose what grant_types/flows are allowed for that application

Yes, we could create an application with all grant_types enabled for testing, but that may not be desirable when different types of applications have different behaviours.
In my view, one should create different application types with just the grant_types that make sense to exist for that application.

• For example, one could enable authorization_code for an SPA app, but it wouldn't make sense to enable client_credentials for the same app.
• Similar logic goes for client_credentials, as it would make sense to enable it for Machine to Machine application, but not for a SPA application.

Given the above, I believe SwaggerUI should allow different configurations per flow/grant_type. A similar request was raised in this ticket https://github.com/swagger-api/swagger-ui/issues/4690 and there was even an attempt to tackle this on https://github.com/swagger-api/swagger-ui/issues/4087. The code done by @pablocoberly is a good attempt to solve this issue, but it could still create a scenario where the user selects an application that doesn't support all the flows in the OpenAPI spec. That code could still be useful if one wants to use different applications that support the same set of flows but each application uses a different user database.

Describe the solution you'd like

A simple way to achieve this is to allow an overwrite of the configuration per flow. For example, and given the example above, one could define the config like this:

  ui.initOAuth({
    clientId: "your-client-id",
    clientSecret: "your-client-secret-if-required",
    realm: "your-realms",
    appName: "your-app-name",
    scopeSeparator: " ",
    scopes: "openid profile email phone address",
    additionalQueryStringParams: {},
    useBasicAuthenticationWithAccessCodeGrant: false,
    usePkceWithAuthorizationCodeGrant: false,
    oauth2FlowOverwrites: [
      ["client_credentials", {
        clientId: "your-client-id-that-supports-client_credentials-flow",
        clientSecret: "some-secret"
      }],
     ["password", {
        clientId: "your-client-id-that-supports-password-flow",
        clientSecret: "some-secret"
      }]],
  })

The end result would be something like this:

I created a PR https://github.com/swagger-api/swagger-ui/pull/9312/files with a basic implementation for this functionality just to support the feature request. Code not ready for production!

Start with initOAuth and the configuration options in dev-helpers/dev-helper-initializer.js, then review the related attempt in pull request #9312 and the earlier issues #4690 and #4087. The requested behavior is separate client configuration for each OAuth2 flow, with the existing defaults still available; completion should cover the flows shown in the example without requiring one application to support all of them.