Forum Discussion
Question for OAuth setting for "Try me" function in APIM developer portal
I am working on a APIM deployment that will have developer portal available to developers. Login to portal will only allow Azure B2C accounts and thus will have OAuth already performed.
On the APIM instance settings in Azure portal the "OAuth 2.0 + OpenID Connect" section has a option to create OAuth server for B2C, which then can be used for each API. The "try me" function for that API in the developer portal can then use this OAuth server to perform OAuth and use the token.
As we have already performed OAuth for developer portal login itself, so I don't want users to perform OAuth twice for better user experience.
But one thing I am unsure off is if either there is a global jwt token validation policy or a API specify jwt policy requiring OAuth tokens, then if I don't set the OAuth for "Try me" function, will that succeed or fail?
And are there any other security/general concerns if we don't set the OAuth for "Try me" function in developer portal.
3 Replies
Yes, 'Try it' fails with 401 if your API enforces JWT validation. Portal login tokens are not reused for API calls.
No security risk - just poor UX.
To avoid a second login: use the Authorization Code flow - the existing B2C session silently issues a new API token. Register a separate app for the console and republish the portal.
If you secure APIs in Azure API Management (APIM) with a JWT validation policy (e.g., validate-jwt), then the “Try it” console in the developer portal must present a valid access token. If you don’t configure OAuth for the “Try it” function, calls will fail against APIs that enforce token validation. The portal login token (via Azure AD B2C) is not automatically reused for API calls but the test console requires its own OAuth configuration.
Portal sign-in and test-console authorization are separate in APIM. The portal identity proves who can use it; an OAuth 2.0 authorization server lets the test console obtain an access token and add it to the API request. If you omit it, the console will not automatically reuse the portal-login token. A global/API validate-jwt policy will reject the request unless the caller supplies a valid Authorization bearer token another way.
You can still avoid a second credential prompt: use authorization code flow with the same B2C/Entra session, so the provider can often satisfy the token request silently, while issuing a token for the API’s audience and scopes. Register the test-console client separately, use its exact redirect URI, and validate issuer, audience, expiry, signature, and scopes or roles in the policy. Keep test-console scopes least-privileged; do not expose broadly privileged client-credential secrets in the portal. Re-publish the portal after OAuth changes.
