If an APIC user creates a 3rd Party OAuth provider in the APIC Resources, the Introspection URL will remain static and if you attempt to set a property to it or set properties on any fields, it will be ignored when the object is created on the gateway.
This poses an issue in a devops process if the company enterprise requires different OAuth endpoints in different environments, and if the environments (catalogs) belong to one APIC cloud instance.
- Modified API Export: You may have multiple 3rd Party OAuth Providers created (e.g. 3rdParty_DEV, 3rdParty_QA, etc), and when the API is deployed from DEV to QA, the API swagger will be updated for QA to have the security definition updated to use 3rdParty_QA rather than the 3rdParty_DEV. This may not be acceptable because this modifies the source code, which will present different code sources for each environment.
- Separate APIC Cloud Instances: Have separate APIC cloud instance per environment, which then allows you have a 1 to 1 mapping between each APIC OAuth Resouce in each APIC cloud instance to an environment. This may be what some companies have and may accomodate for, but for some, 1 APIC cloud instance will publish to multiple gateways in its respective environment.
- Host Alias Mapping: The Introspection URL input on the APIC OAuth 3rd Party Provider Resouce will use a host alias name that will be set on the gateway. The Host Alias will map the OAuth endpoint respective to the environment.
In the diagram below the Host Alias “oauth-url.com” is set to an environments OAuth provider endpoint. Then in APIC, the 3rd Party OAuth Provider Introspection URL will use this URL. Every gateway Host Alias will be set to a different IP, which will be mapped to its respective OAuth provider per environment.
The diagram below shows a sample topology. During runtime, as each request invokes the API and triggers the 3rd Party OAuth Introspection call, the request will be using the “oauth-url.com” Host Alias which will be mapped to the respective OAuth Provider.