I'm looking for a away to protect my APIs in APIM, I really don't understand the difference between Subscription Key and OAuth 2.0 using Access Token. Can we use OAuth2.0 instead of Subscription Key or use both ?
As per my understanding,
In Simple:
Subscription keys are the common way to access the Azure APIs in APIM instance.
If the API requires subscription key to access it by the user, then we call it as secured API. Otherwise, it is unsecured API and mostly used by the public.
But for unsecured access to that certain APIs, configuring another mechanism to secure client access is recommended.
Those other mechanisms to secure access to APIs in APIM were OAuth 2.0, Client Certificates, and Restring caller IPs.
As DeepDave recommended this SO Thread states that,
It is not possible to use OAuth token to identify client, but you can use it for rate-limiting and logging (of sorts).
You can identify the users and their level of access (To how many products/APIs, they have access) easily by using subscription keys because they are associated on 3 scopes like Product level, All APIs level, or an individual level.
OAuth 2.0 provides extra layer of security both in Authentication and Authorization.
To Implement the other mechanisms like OAuth2.0 or other, these references are useful:
Protect APIM using OAuth2.0
API Protecting Mechanisms in Azure
A Workaround of Protecting APIs in Azure API Management using OAuth 2.0 Client Credential Flow & test using Postman
Extra layer of security to avoid unauthorized access to APIs using OAuth 2.0
Related
This is a follow-up to the question about how to secure subscription keys when calling API from client-side code.
I read through Microsoft's documentation that states: "By publishing APIs through API Management, you can easily secure API access using subscription keys." However, if you have a client-side app that wants to call API, the subscription keys will be visible to anyone who inspects the HTTP request in browser web tools.
Now anyone can take your subscription keys and make API calls on your behalf.
Am I missing something here?
I have a google cloud function in Java.
Client will invoke the function using HTTP trigger URL.
But that is not secure. I have gone through some docs saying that you should pass a token or client ID and then verify it in server side.
Can anyone explain that in detail and please provide a code example if any.
My doubt is to authenticate the client while they invoke the function using Http trigger
This page explains quite well all the capacity that you have to authenticate a requester on Cloud Functions.
If you have users, the best way is to use Firebase Auth (our Google Cloud Identity Platform which is simply a more advance solution than Firebase Auth with more features)
However, you need to grant all you user with cloudfunction.invoker role, to allow them to invoke the Cloud Functions. It could be difficult. You can also perform the check on your side, but in this case you remove the security (filter) layer of google and you have to check all the traffic by yourselves (not really safe, in term of billing and in case of attack).
The latest solution, API keys, is not recommended, especially for the users. But for machine to machine it's sometime the only solution. However, there isn't out of the box solution and for this I wrote an article, that explains how to create a Cloud Endpoint (or now a Cloud API Gateway which is the serverless solution of Cloud Endpoint with ESPv2) to accept API Keys.
With this latest solution, if you change your security definition, you can also accept OAuth2 tokens coming from Firebase Auth (or Cloud Identity Platform), but this time, you don't need to grant all the users on your Cloud Functions IAM role. The token only need to be valid and it's the Cloud Endpoint service account which is used to perform the call (and thus which needs to be authorized on the Cloud Functions).
In addition, because you can accept OAuth2 token, you can also accept non Google token, and thus have your users in any IDP OAuth2 compliant (KeyCloak, Okta,...)
You could use external OAuth server like keycloack (https://github.com/keycloak/keycloak), or use somethging like Json Web Tokens -- https://jwt.io/ -- available for various languages, siutable for microservices.
I'm the administrator of a Bim360 Docs Hub,and i'm trying to retrieve some data from the forge API. I've already created a test app, and i get a Bim 360 Account Id.
I'm not able to get an authentication bearear token (OAuth), to make simple get requests towards projects.
Where do i get the auth token ?
Thanks
See tutorial here to aquire OAuth tokens and note that you will need different permutations of OAuth scopes (esp. data:read data:write etc.) for different operations, as is specified in the docs of each and every API, see an example here.
You may use a RESTful client like Postman to talk to our APIs and manage the authentication flow and operate on response data with JavaScript as you like so as to build workflows such as to create a new project.
Last but not least before you can access BIM360 APIs make sure you provision access to your app.
I am using Azure API Management to provide API gateway for some APIs. To set up a policy for a particular Api, I have used a Property(Named Value) to restore user metadata and then I assign it into a Variable in incoming request body. When adding a new user I need to add metadata for the new user in to the json. The property value has grown and exceeded the limit now and I cannot add more info to it anymore. I am wondering what the best way is to restore my large metadata in order to be accessible in API Management policy?
Update1:
I have switched the Authentication process from Azure to Auth0 so I can add the user metadata to Auth0 app_metadata and then in Azure policies I validate JWT from Auth0 and obtain token claim(app_metadata) explained in this article. By doing so I can solve the large user metadata (json) issue however this doesn't solve other non-related user metadata stored in other Properties(Named Value) and moreover the API gateway inbound policies are growing and becoming a huge bunch of logic which is not easy to manage and maintain.
At this stage I am looking for a solution to handle all the API gateway inbound policies in a better way and more manageable environment i.e. C#. So my two cents is to implement the API gateway inbound policies in a new .net Api and call this new API in the existing API gateway inbound policies so that it can play a bridge role between Azure API gateway and existing API however I'm still not sure if this is acheivable and whether existing API can be called via new API directly or it should be called via Azure API gateway in some way!
At this point you have to either store it in multiple variables or hardcode it in policy directly.
After more research I ended up with this solution which basically suggests to restore user metadata in Azure Cosmos DB and call Cosmos API in API Management Policy to access to the metadata and also the Cosmos API call can be cached in the policy.
What I understand is Enterprise API from Box works only with server-server JWT auth and not like OAuth2 based authentication.
Box integrations which haveOAuth2 based authentication support only Content API and not the Enterprise API.
Is there way to have OAuth & Ebterprise API at the same time? (I essentially want to manage users & groups any third party enterprise)
Any thoughts/pointers? Thanks in advance!
What I understand is Enterprise API from Box works only with server-server JWT auth and not like OAuth2 based authentication.
This is not correct, though I can see how you could arrive at that understanding. You can work with the Box Enterprise API using traditional 3-Legged OAuth. In fact, for many years 3-Legged OAuth was the only way to work with the Box API.
In order for a 3-Legged OAuth access token to make Enterprise API calls:
The appropriate Enterprise scopes must be selected in the app configuration.
The token must have been issued for a user with enterprise admin/co-admin privileges.
The relationship between JWT auth and the Enterprise API is one of convenience. Enterprise API apps are often non-interactive server-side scripts and/or scaled out to multiple processes. In these scenarios JWT is much easier to work with than 3-Legged OAuth.