I have an API that is hosted on GCP (no matter if its Compute Eninge, App Engine or any other) and I want to give access to it for selected applications that run outside of my company. I do not need such sophisticated service like Apigee (it is too expensive also), I just want to distinguish applications that call my API and do some individual restrictions for each (like which endpoint they can call).
As I have done some research I think that Cloud Endpoints + API Keys fits my requirements. I could create API Key for each client (API Key is sent in query, so I suppose I can get it in my backend?), but I am a bit confused if it is "the right/recommended" way. As stated here https://cloud.google.com/endpoints/docs/openapi/when-why-api-key#api_keys_provide_project_authorization it should help me to identify project, or rather for my case application, which is communicating with my API, but it feels like its more dedicated for apps that run within my organizations because it can have access to Google services Apis (like I should not give API Key to someone else outside, although I can even restrict IP addresess which can use it).
Would be glad to hear if someone had a smiliar goal and if solved it this way.
Related
I am trying to create a REST API (via Firebase cloud functions) and release it to my clients to allow them creating their mobile apps. The mobile apps they will be creating are used by public users. However, users are not supposed to deal with our APIs and thus authentication. So I don't need end user authentication. It's up to our clients (app makers) to use a "client id" and an "api key".
Based on what I have researched, Firebase Admin SDK might not be a good solution for this end since we're concerned about client level authentication.
I am looking for a standard solution to generate api-keys for the 3rd party clients. This key generation is not a manual process but rather a service that clients will use to obtain a key. Something like google map api for 3rd party developers. We want to keep track of whitelisted clients without needing their app users to deal with authentication.
I'd appreciate suggestions and guidelines to find the best solution for our REST APIs.
The first solution that comes to my mind is thew new Firebas App Check. It would restrict any access beside the Apps and Web pages you have whitelisted for your project. I don't know if that is possible in your usecase (how the cooperation with the other apps look like) but I would deffinitely try this first.
We're currently working on our API based on Google Cloud Functions together with Google's API Gateway.
As every customer who buys access to our API should get their own API key, I'm wondering if there's a ways to create those API keys using and API. What I want to achieve is that a customer is able to request an API key in their own settings, so klick a button, this triggers a function, generates a key and shows it to the customer in front end.
After searching for quite some time, I didn't find anything about how this could be built. It could also be that my approach to this is totally wrong - if that's the case, please roast me and give me some advice with it!
Thanks in advance for your answers!
Google credentials can not be created programmttlcy they must be created manually.
In fact, there is something. A while in beta (more than 1 years ago) and quickly back in alpha, and undocumented (or pretty bad)
As you can see in the gcloud alpha command, you can use API Keys with CLI and API. Use this command to test and discover more how you can use API keys.
gcloud alpha services api-keys create --display-name="created by API" --log-http
USE WITH CAUTION
Firstly, I have no update on this API, will it survive or not? The lifecycle and the "no news" from Google is strange and keep in mind that the API can be removed at any time.
Secondly, API Keys is a long lived token and it's not recommended for security reason. But sometime, it's better than nothing, so to use it when no others solution are possible, it's acceptable. Else, prefer OAuth .
Eventually, API Keys authenticate a project, not a customer/user. You won't have it in header data after the API Gateway request forward. Only the Project ID (or Number, I don't remember). Thus, if you want to differentiate each customer/user, you need to create different projects, and generate a keys in each project. Same thing if you implement rate limit on API Gateway: Quotas are per project and not per API Keys.
I've looked at a few places, Including this post and the firebase panel
Is there no way to use these api's to secure these endpoints using an api key you create per client who uses your cloud functions?
I'm able to block every one putting a restriction on the Browser key, but I would like to create a new api key, and use that as a way to authenticate my endpoint for various clients.
Creating a new api key, and using that as a parameter in my query doesn't work (don't now if I'm doing anything wrong)
Is there a way to do this?
Option 1: handle authentication within the function
https://github.com/firebase/functions-samples/tree/master/authorized-https-endpoint
Adapt above to use clients/keys stored in firestore
Option 2: Use an an API Gateway
Google Cloud Endpoints (no direct support for functions yet, need to implement a proxy)
Apigee (higher cost, perhaps more than you need)
Azure API Management (lower entry cost + easy to implement as a facade for services hosted outside Azure)
there are more..
The above gateways are probably best for your use case in that the first two would let you keep everything within Google, albeit with more complexity/cost -- hopefully Endpoints will get support for functions soon. Azure would mean having part of your architecture outside Google, but looks like an easy way to achieve what your after (api key per client for your google cloud / firebase functions)
Here's a good walkthrough of implementing Azure API Management:
https://koukia.ca/a-microservices-implementation-journey-part-4-9c19a16385e9
Not to achieve what you are after, as far as firebase and GCP is concerned your clients is your specific business problem.
One way you could tackle this (with the little information that is provided);
You need somewhere to store a list of clients + their API key (I would use firestore)
For the endpoints you want to secure with a client-specific API key you can include a check to confirm the header exists and also exists in your firestore client record.
Considerations:
Depending on your expected traffic loads and the the number of firestore reads you'll be adding, you might want to double check this kind of solution will work for your budget.
Is the API-key type solution the only option you must go for? You Could probably get pretty far using the https://github.com/firebase/firebaseui-web and doing user checks in your function with no extra DB read required. If you go down this path most of the user signup/ emails / account creation logic is ready to go.
https://firebase.google.com/docs/auth/web/password-auth#before_you_begin
Curious to see what some other firebase users suggest.
Google offers Datastore for the GCP which is the "C" in CQRS. But, where is the "Q" (Query)?
Datastore has, maybe justifiably, two very big limitations to making it a viable query system:
No subtext searching
No sorting on fields unless they've been filtered on
Google Cloud offers an "App Engine Search API", but this is not an endpoint API. It is a library API. Meaning, one must manage the infrastructure around it.
With Datastore, one of the advantages is that I can manage access via rules in a "server-less" way, so that my client app can directly deal with the Datastore (I.e "server-less").
With search API, I must write an application to index my documents using one of four supported languages, expose end points, manage scalability... Defeating the purpose of using server-less services like Datastore if I have to do all this manually anyway.
Does Google Cloud offer something more of a compliment to Datastore in the way of searching, filtering, ordering in a server-less way? Will they?
With Datastore, one of the advantages is that I can manage access via rules in a "server-less" way, so that my client app can directly deal with the Datastore (I.e "server-less").
I do not think Datastore's security model is powerful enough for direct remote client (e.g. web browser) access. Specifically even with IAM for Datastore it is missing record-level permissions. The Firebase Realtime Database with its security rules would seem more appropriate.
With search API, I must write an application to index my documents using one of four supported languages, expose end points, manage scalability
Similarly you can't do direct remote client access to the search API. However the Search API is designed to work with AppEngine, which manage individual machines/instances for you and implements autoscaling based on request rate and response latencies.
Perhaps to get a truely 'serverless' setup you could combine Firebase and Algolia as described here?
Is it possible expose and sell google cloud endpoint as an Api? I have created a simple but useful cloud endpoint. I want paid customers to access it directly as an api. How will I create a client-Id or API key dynamically for such clients, etc? For example, google also sells search service as API, where any user can go generate its own API key and Secret, and start using google search service.
Right now, no, or at least not without a lot of work.
The current product was designed with the "same party" use case as the primary goal (the API producer and consumer are the same). There are a number of things that would need to be added to the product to enable the kind of use you're describing. First and foremost on that list would be some kind of API consumer dashboard (like the one Google offers developers for consumers of its APIs).
Endpoints is built on the same API infrastructure as the rest of Google's APIs, and Google does offer this feature on some of its APIs. That may give you a sense of where the product is headed in future iterations.