I'm doing some tests with Azure APIM and have already published an API on the developer portal. I have the docs, have it secured using OAuth2 with Azure AD with client_credentials flow. I can invoke this API from Postman and from the developer portal.
Unfortunatelly, the client_id and secret are set on the configuration and the developer cannot self service them. Is there a way to do so instead of having to add it manually to each developer?
I was looking for something like this: https://tyk.io/docs/tyk-stack/tyk-developer-portal/portal-oauth-clients/
Azure APIM itself doesn't act as an identity provider like tyk but instead uses Azure AD (or rather any OAuth 2.0 provider).
The configuration in the docs is primarily to get the Developer Portal Console (the one used to test APIs) to work. For the actual API calls, there is no configuration required.
The validate-jwt policy is what takes care of preauthorization of requests.
Since you are looking for the client credentials flow alone, you could simply expose a portal that can create the required app registrations on your Azure AD using the Microsoft Graph API and expose the client id/secret to your users.
The current developer portal doesn't support this as of today but is something you could contribute to if you wish.
Related
How to call the secured API management linked APIs configured in azure portal when developing locally using SWA CLI? All I observed in the SWA configuration is meant for functions as APIs not the APIM.
https://learn.microsoft.com/en-us/azure/static-web-apps/apis-api-management
When adding API Management APIs to an azure static web app, an automatic proxy product is created on APIM securing access to the API for this app via /api prefix on the static web app domain. I did not see any mentions of how this works for local development to pass the user claims from SWA emulator to the API via that proxy?
I was trying to do this recently and I don't think it's possible. My solution was to add a proxy to my dev server (in my case vite) to proxy all requests to the /api route to the Api Management URL, setting the necessary subscription key header.
I would like to integrate Foundry with the central API gateway of our organisation.
Access of the gateway should be granted via OAuth2 via the "Third Party Applications" functionality of Foundry.
Now I am facing the problem, that our API Gateway only supports the Client Credential Flow in which no Authorization Token is used but only the Access Token. Is there a possibility to make Foundry follow the simplified flow w/o Auth token?
Foundry supports the OAuth2 Authorization Code grant which provides delegated access to Foundry resources and services.
Support for the OAuth2 Client Credentials grant, which allows service user access, is under limited release with a few customers. If it’s not available for you please reach out through your internal support channels. A general release is expected early this spring, I'll try and update here if that timeframe slips.
We want to make our APIs available to external systems.
Our APIs are protected by "Access tokens" using OAUTH2 and Azure AD B2C as an Identity Provider.
Unfortunately, B2C does not support the "Client Credential Flow", so external systems cannot get tokens from B2C by passing their client id and their secret.
We are thinking of fronting the APIs with Azure API Management, and providing the external systems with Subscription Keys. Then once we verify the subscription key in API Management, we want to acquire an Access Token to call our back-end.
Is this possible? It seems like not because of the Client Credentials flow missing. However, I've seen videos from APIM experts claiming that it is possible. I'm I missing something? Does APIM have special treatment?
I have created a .NET Core API and deployed it as an App Service in Azure. On top of that, I have an instance of Azure API Management. Now I want the API to be only accessible through the APIM.
During the free testing phase, i restricted the access to the API to the IP of the APIM. As i do not expect my API to have high traffic and to save costs, i now switched to free and consumption tier.
As my APIM uses the consumption tier, there is no static IP that I could use to restrict the API access.
As my App Service uses a free plan, neither VNet Integration nor incoming client certificates are available.
Is there are a way to secure a free App Service API with a APIM in consumption tier with Azure except from implementing it myself?
You have a few options with Consumption SKU in mind:
Basic auth - make APIM send a well known secret and check for that secret in API App.
Client certificate authentication - make APIM use client cert to connect to API App and check for it there.
I have an ASP.NET Core REST API Service hosted on an Azure Web App. I own its source code and I can change it if required.
I am planning to publish REST API Service with Azure API Management.
I am adding Azure AD authentication to the Azure API Management front. So, the API management front is secured. All the steps are is described here.
All good so far. Here is the question (or challange?) :
Considering that my backend REST API Service is hosted on Azure and publicly accessible, how do I protect it against the request calls other than the API Management Calls?
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
A link to a code sample or online documentation would be a great help.
Update
While there are some overlaps with the follwoing question:
How to prevent direct access to API hosted in Azure app service
... part of this question is still outstanding:
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
You can enable static IP restriction on your WebApp to only allow incoming traffic from the VIP of your APIM Service facing ( keep in mind in some specific scenarios , the VIP may change and will be required to update the whitelist again).
Clients ==> AAD==> VIP APIM Service <==> (VIP APIM allowed) Web App
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions