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.
Related
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 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.
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.
Alright, A friend and I are developing an App where I'm developing the back-end and he is developing the front-end. The project is separated into two repositories the front-end and the back-end, and we need to implement a payment API.
Now, since we're using the REST API Concept, we communicate both ends through JSON data.
My question is, when we're making the connection to the payment API, who needs to execute that request? The front-end or the back-end?
I know it's a silly question, but first timer here.
The backend will obviously process the payment, I'm not sure which payment API you're going to use. But depending on the API you go with, the implementation will vary. But the actual processing of the payment will be processed in the backend for sure.
It completely depends on the API.
In some cases, a payment can be accomplished via a secure web service call, which would be issued by your friend's REST service. The front end will still need to collect data (e.g. payment amount and card number) and may also need to collect additional information to satisfy the API (e.g. IP address or browser signature, for risk management purposes).
In other cases, the payment is sent directly to the service from the browser. The role of your application would be to render an iFrame housing a page that is reached via SSO. The back end may need to call a service to retrieve an SSO token, or may have to compute an SSO token using a shared key.
You should probably refer to the payment API's documentation. They often have very specific guidance which you must follow carefully in order to achieve payment card (PCI-DSS) compliance. There is nothing special about "payments" that says that allows StackOverflow users to guess anything about its API.
In my application , I use the following APIs of the companies API,
https://api.linkedin.com/v1/companies/id={id}
and
https://api.linkedin.com/v1/companies/{id}/updates?event-type=status-update
With the new API program, do I need to change my existing application ? I find the description on the linkedin developer website regarding the same as not comprehensive enough. If I need to continue with the app, do I really need to get into a partnership program with linkedin or can I continue like I do currently.
We recently contacted the LinkedIn Support regarding the changes.
So first endpoint will be available to you without getting into PartnerShip program. The following endpoints are the only ones that will remain available for use:
Profile API — /v1/people/~
Share API — /v1/people/~/shares
Companies API — /v1/companies/{id}
The second Endpoint will require Partner Ship program with LinkedIn you can apply here
But it will not involve code changes because they will give privileged access to your App. At the time of applying for partnership program they will ask for LINKEDIN_APP_KEY and LINKEDIN_APP_SECRET. They will provide access to these KEY and SECRET.