When generating open api v2 or open api v3 spec with OAuth2 protected APIs, the generated spec does not correctly refer the security definition from the security requirement in the each path definition.
This leads that swagger UI does not properly set the given OAuth2 credential when calling OAuth2 protected APIs.
While digging the issue, I've found that security definition reference is broken from the security requirement.
In current implementation in case of OAuth2 protected APIs, the security definition name is hard-coded with oauth2.
So, when trying to refer such definition for the swagger UI to populate given credential when calling OAuth2 protected APIs, we should use oauth2.
But, when creating OAS2 and OAS3 documentation, current implementation composes the such reference name with oauth2 and following postfix _$flow which stands for one of OAuth flow (implicit, clientCredentials, access_code and etc.) and adds composed name in the security requirement field.
For example., if OAuth2 security definition supports OAuth2 clientCredentials and implicit flows, then the reference names are created: oauth2_clientCredentials and oauth_implicit which do not refer anything to the security definition.
To fix this problem
Do not add any postfix for oauth2 authentication for the reference name composition
Do not create multiple security requirement if the supported OAuth2 flows are multiple
When generating open api v2 or open api v3 spec with OAuth2 protected APIs, the generated spec does not correctly refer the security definition from the security requirement in the each path definition.
This leads that swagger UI does not properly set the given OAuth2 credential when calling OAuth2 protected APIs. While digging the issue, I've found that security definition reference is broken from the security requirement.
In current implementation in case of OAuth2 protected APIs, the security definition name is hard-coded with
oauth2
. So, when trying to refer such definition for the swagger UI to populate given credential when calling OAuth2 protected APIs, we should useoauth2
. But, when creating OAS2 and OAS3 documentation, current implementation composes the such reference name withoauth2
and following postfix_$flow
which stands for one of OAuth flow (implicit
,clientCredentials
,access_code
and etc.) and adds composed name in the security requirement field.For example., if OAuth2 security definition supports OAuth2
clientCredentials
andimplicit
flows, then the reference names are created:oauth2_clientCredentials
andoauth_implicit
which do not refer anything to the security definition.To fix this problem