Switching between OIDC authentication and api-key authentication

Hi, I use Tyk OSS and api specifications in openapi format. At the moment I use api-key-based authentication //learn.openapis.org/specification/security.html#api-keys . I create keys via /tyk/keys specifying the api id. In the header I specify the key-value of this key and everything works fine.
I also tested working with an OIDC provider (I use keycloak). I use the clientToPolicyMapping setting in the openapi specification specifying the required policy and clientId (x-tyk-api-gateway → server → authentication → oidc → providers). When testing, I get a token in keycloak, substitute it in the header and check. Everything works fine here too.
The question is, can I give clients the option to use either one or the other authentication mechanism? If the client wants it, it uses api-key authentication, if not, it chooses oidc? I tried to combine these authentication types in the specification, but I made both mechanisms work only simultaneously (i.e. you need to specify both: api-key in the header and specify the token).
Example of a specification file:

Summary

{
“components”: {
“schemas”: {},
“securitySchemes”: {
“OpenID”: {
“openIdConnectUrl”: “{{openIdConnectUrl}}”,
“type”: “openIdConnect”
},
“api_key”: {
“in”: “header”,
“name”: “api_key”,
“type”: “apiKey”
}
}
},
“info”: {
“title”: “Sample API”,
“version”: “0.1.9”,
“description”: “example of api for wiremock”
},
“paths”: {
“/get_method”: {
“get”: {
“summary”: “Returns a list of users.”,
“responses”: {
“200”: {
“description”: “A JSON array of user names”
}
},
“description”: “Optional extended description in CommonMark or HTML.”,
“operationId”: “/get_methodGET”
}
}
},
“openapi”: “3.0.0”,
“servers”: [
{
“url”: “http://wiremock-gui.test-default.int.e-kama.com/em”,
“description”: “wiremock host”
}
],
“security”: [
{
“OpenID”: ,
“api_key”:
}
],
“x-tyk-api-gateway”: {
“info”: {
“id”: “{{apiId}}”,
“name”: “Sample API”,
“state”: {
“active”: true
}
},
“server”: {
“listenPath”: {
“strip”: true,
“value”: “/TykTestOIDC01/v1”
},
“authentication”: {
“enabled”: true,
“baseIdentityProvider”: “”,
“oidc”: {
“enabled”: true,
“header”: {
“enabled”: true,
“name”: “Authorization”
},
“providers”: [
{
“issuer”: “{{issuer}}”,
“clientToPolicyMapping”: [
{
“clientId”: “{{clientId}}”,
“policyId”: “test_oidc_policy01”
}
]
}
]
},
“securitySchemes”: {
“OpenID”: {
“enabled”: true
},
“api_key”: {
“enabled”: true
}
}
}
},
“upstream”: {
“url”: “https://wiremock-gui-ei.test-default.int.e-kama.com/em
}
}
}

@Aleksandr_Romanov I think you might be looking for something like our looping feature.

The other alternative I think would be to set the primary auth as Standard Token but expose an endpoint that can generate the oauth token but also create a similar StandardToken that maps to the oauth token for observability

Thank you very much for the information! I will look into these options in more detail