API Management

Microsoft Azure API Management is a turnkey solution for publishing APIs to external and internal consumers. Quickly create consistent and modern API gateways for existing backend services hosted anywhere, secure and protect them from abuse and overuse, and gain insights into usage and health. Plus, automate and scale developer onboarding to help get your API program up and running in no time.

How can we improve Azure API Management?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.

You can remove your votes from an open idea you support.

To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter your idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

In some cases, Management Portal and Developer Portal should not be published into the Internet so that anonymous abusive users cannot attack the Portal, such as DDoS.
If we can set a rule with IP address filtering like a firewall service, it would be very helpful to protect our API Management service.

A major bonus when using an API management system should be that it helps you secure your backend APIs using standard techniques. Other API management systems (such as Kong, see https://getkong.org/plugins/oauth2-authentication/) have support for this, where the APIm acts as a Bearer token store and validates the tokens for you.

Obviously, this will only work for the Client Credentials and possibly also Resource Owner Password Flows, as the others require additional UI, but still this would be a very nice add-on, which enables you to leverage OAuth for backends which are actually OAuth-agnostic.

Azure APIm would then also need a notion of Client IDs and Client Secrets, and would also need to keep a Authentication Token store somewhere. Implementing this in a - for the developer - nice way would require delegating the registration process completely, and also implementing the Authorization Server completely.

Azure APIm supports OAuth 2.0 very nicely in the portal, but this is more for the backend side, assisting in implementing the OAuth backend.

Are there plans on doing anything like this? Even if you use the AAD, you still end up needing a lot of custom code to even get the Client Credentials Flow up and running.

(Or, which is not entirely out of the question, did I completely get it wrong how you would do this).

Best regards,
Martin

A major bonus when using an API management system should be that it helps you secure your backend APIs using standard techniques. Other API management systems (such as Kong, see https://getkong.org/plugins/oauth2-authentication/) have support for this, where the APIm acts as a Bearer token store and validates the tokens for you.

Obviously, this will only work for the Client Credentials and possibly also Resource Owner Password Flows, as the others require additional UI, but still this would be a very nice add-on, which enables you to leverage OAuth for backends which are actually OAuth-agnostic.

Ability to create an API in Azure API Management that will OAuth to the origin api. I don't want my users to oauth, the Azure API key is enough security for that. I just want my Azure API to access the origin API through OAuth.

We are currently consuming our APIs via various clients, including Microsoft Excel and various integration tools. These tools do NOT support the current front-end API authentication methods.
One solution is to enable Basic Auth support in the front-end API.
The existing username and subscription key could be used as the credentials, but the API Management would accept them in the standard base64-encoded Authorization header.

Currently Proxy Authentication supports HTTP Basic and Client Certificates. In an effort to make a unified OAuth 2.0 Gateway, we have some services using other OAuth 2.0 providers for the security in the backend and would like to use something like Client Credentials flow or the On Behalf Of flow to call the existing service keeping the front with only one OAuth implementation.

I did used the delegate option and am able to Sign User Programmatically by generating SSO URL (generateSsoUrl). Now I have problem in Signingout, once user try Sign-Out from Azure APIM Developer portal, microsoft delegate the call to our CUstom AUthentication server, and we end the users session, and redirect them back to base url of developer portal. Here User see the Sign-In option again.

However If I paste the previous SSO URL (generateSsoUrl) into browser it allows the user to log-in, which is a security violation.

I did used the delegate option and am able to Sign User Programmatically by generating SSO URL (generateSsoUrl). Now I have problem in Signingout, once user try Sign-Out from Azure APIM Developer portal, microsoft delegate the call to our CUstom AUthentication server, and we end the users session, and redirect them back to base url of developer portal. Here User see the Sign-In option again.

However If I paste the previous SSO URL (generateSsoUrl) into browser it allows the user to log-in, which…

These are OK, but they are not enough for many customers. In particular, many customers require giving developers or architects permissions to define and manage APIs without touching anything else (i.e no product, security, or similar configurations).

While this is potentially possible to do using custom RBAC roles, doing so in a way that keeps everything working correctly and that does not break when the PG changes the way the portal works is non-trivial.

So having a role that grants that level of behavior without forcing the user to grant full contributor role would be very nice.

These are OK, but they are not enough for many customers. In particular, many customers require giving developers or architects permissions to define and manage APIs without touching anything else (i.e no product, security, or similar configurations).

While this is potentially possible to do using custom RBAC roles, doing so in a way that keeps everything working correctly and that does not break when the PG changes the way the portal works is non-trivial.

Allow the admin to add users from AzureAD so they can be configured before the user actually logs in.

With having to wait for the user to login, then the admin to configure them with appropriate groups within APIM (not AzureAD groups) this increases the time before the user can actually make use of APIM depending on how long it takes the user to get around to logging in and the admin to add them to the right groups.

We have legacy websites only support TLS 1.0 and SSL 3.0, and it can't recognize the clienthello extensions while the TLS shake process, and this cause we can't use APIM to access our backend websites. So is it possible to disable TLS 1.2 or disable the clienthello extensions

Currently when deploying an APIM in VNET Internal Mode, the default rule for 0.0.0.0/0 must direct traffic to Internet. It would be great from a security perspective to be able to have that internet bound traffic be scanned by an NVA before reaching the internet and vice versa.

Currently if you chose to use subscription key as authentication method even if you add Oauth it will always require the subscription key. We have scenarios where we need to be able to use either one of these, need to allow OR option in policy definition currently it is always AND.

Also since all subscription keys are user bound and not "application bound" long term use in an production system this may be problematic.