Skill Level: Any Skill Level

This write-up documents the limitation and solution of the APIC 3rd Party OAuth Introspection URL not being able to be set to a property value (e.g. $(oauth-url.variable)), resulting in not being able to promote APIs without modifying the source.


  1. The Issue

    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.

  2. The solution

    • 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 “” 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 “” Host Alias which will be mapped to the respective OAuth Provider.



2 comments on"API Connect v2018 & v10: Set Introspection URL on Third Party OAuth to different environments for devops operability"

  1. So this is a great idea with 2 problems

    1. The password is not likely to be the same and that is something that also potentially should not be known but DataPower stores it in clear
    2. It only works if that is an IP so for us that doesn’t work at all however the actual host in the properties of the API Connect might

    We are still looking into a viable solution that is good performance wise, Security and other for the first issue

Join The Discussion