After reading each of these Q&As,
google api machine learning can I use an API KEY?
how to use google AI platform online predictions?
How to authenticate GCP AI Platform Predictions using HTTP requests
I am still at a loss to know how to enable simple authentication for the AI Platform Predict API that doesn't need any sign-ins or OAuth screens.
My scenario is the following: we have a static website which allows the user to enter some data, the website (client) sends the data to the model for prediction via the API, and when the results come back, the website shows them to the user. We don't want the user to have to sign in or identify themselves in any way. Just input some data, push a button, and get the results.
However, as far as I've been able to search, there is no way of doing this (the documentation on authentication is in my view confusing, there are multiple overlapping articles and it is difficult to determine what applies in a specific case); you have to use some sort of OAuth which makes the user sign in with a Google account.
Is there really no way to have the website itself authenticated but not the individual users? E.g. using an API key or service account key?
If OAuth is the only way, does that mean users who want to use the website must have a Google Account? And how do I enable it: should I create an OAuth Client ID, or is it the OAuth consent screen?
The recommended practice here is that all the OAuth should happen server-side, where the GCP Service Account JSON key is stored on some backend server.
I am going to answer your question by assuming that your website is hosted on App Engine, but your website could be hosted any where on other GCP products as Cloud Run or any other hosting providers.
In backend webserver you can make the AI Platform predict request using Service Account JSON, then you would need to configure your website to talk to this backend.
Website ----HTTP Request to App Engine URL------> App Engine (code---)--------> AI Platform
So the App Engine backend performs the authentication on behalf of the website client, as Lak clarifies here; since the requests will be passing your GCP Service Acount JSON Key, then they gain access to send the specific HTTP requests to their backend server, which makes the AI Platform calls.
In your case, you do not want the users to access your Google data, you simply want provide them access to your own AI Platform model.
Basically you can just use Client Library on server-side and it automatically does OAuth for you, as long as environment variable is set to Service Account key.
Note: You only need to do Google OAuth IF you want access to a person's Google resources (e.g Google Doc, Calendar, GCP project, etc)
Related
I am currently developing a client-side app where users login using e-mail/password against MongoDB Atlas. The backend runs completely serverless.
All logged in users should be able to upload and retrieve images from GCP - Storage bucket without a visible login, which means the application should authenticate for every user on the background.
I was thinking about using Google Service Accounts in combination with auth0, but I don't know where to start...
If someone could help me tell where to start, that would be great :)
The question is difficult to answer. However, here some insights.
The prefered way is to have a serverless backend, AppEngine standard, Cloud Run or Cloud Function for doing this. The user performs its authentication and then exchange security token between the frontend and the backend. When the user want to reach a GCP resource, it asks the backend, which request the request thanks to its own service account.
By the way, it's easy to trace the user request and to serve him only the resources related to it. And you have only 1 service account, for the backend
If you grant access to a bucket to a user, it could download all the files (But maybe there is one bucket per user?). If you chose to limit object access with ACL, the management is complex.
You don't need to have a service account per user (and in any case, you have a quota to 100 service accounts per project), you can use Cloud Identity Platform (CIP) instead of your MongoDB database for authentication (CIP don't perform authorization, you should use MongoDB for authorization and other stuffs related to authenticated user). CIP is Firebase Auth rebranded
I have to develop a RESTful API for a mobile application and I have some concerns about the flow of the communication between those parts. I'm new to the API development for mobile devices and OAuth.
The project in common should work this way:
users are allowed to login using only their Google accounts
the mobile application uses the website API and all the information is stored on the backend
I found a similar question here OAuth on REST API for mobile app and I prefer the first solution from it, but I have some questions about the security of this solution.
1) Should I use OAuth2 for the API? I'm not sure it's a good idea just to send the user's Google ID to the API to get user's data.
2) How can I check on the server that the Google ID is correct and actual? Or it's not important at all?
I'm thinking about this scenario, but I'm not sure it's the best solution:
1) The user logs in on the mobile application for the first time using his Google Account.
2) The mobile application receives Google ID and some additional information.
3) The mobile application sends the Google ID to the server.
4) The server uses OAuth2. It creates an account for the user (saving the Google ID in the database) and returns an access token to the mobile application.
5) The mobile application stores the access token locally and uses it for requests to the server. Once the access token expires, the user has to login in the mobile application again using his Google account.
I have some concerns about using just Google ID for generating a token. I mean, anybody can just use somebody's Google ID to create a token. Bad idea :(
Also should I use JWT better as a token?
Thanks for your help!
You should send the user's id_token to the API instead
There are a couple of different ways in which you can validate the integrity of the ID token on the server side:
a) "Manually" - constantly download Google's public keys, verify signature and then each and every field, including the iss one; the main advantage (albeit a small one in my opinion) I see here is that you can minimize the number of requests sent to Google.
b) "Automatically" - do a GET on Google's endpoint to verify this token
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token={0}
c) Using a Google API Client Library.
As for the workflow, it's mostly correct, except for the last step, where you can instead refresh an access token without prompting the user for permission. Btw, Google's id_token is actually a JWT.
Iam a student and i making my internship. Sorry for my bad englis
The situation
2 people are building an backend for an message system. There are actual and passed messages. The main backend contains all the data from all the messages. This backend pushes only actual messages to and database from an mini backend which only contains the actual alerts. These actual alerts are provided by an api to multiple front ends such as an app.
I need to do research about api gateways which can make the data in the mini backend accesable for external developers. These developers only need to register or request an account so we know which application/developer connects with our api. We don't have end users with user accounts.
The API need to be scalable because in the future (over a couple of months) this system wil replace an old system. The current system needs to be handle more then 5.000.000 requests in a couple of minutes when sending out an emergency message/alert.
My problem
I googled a lot about authentication methods and i read about OAuth2. This is only necessary for authenticate end users with an user account? I dont have that so OAuth is to complex for my situation i think. But when i look in the documentation of several API Gateways like Mulesoft, Amazon API Gateway and some more i always come back by OAuth and not by an simple authentication token system or something.
See this link and then Creating a client registration flow. This uses OAuth or do i understand this incorrectly?
So now my questions
Is there an default method such as google or facebook uses for authenticate external applications by an API key? and how is this method/framwork/idunno caled?
Is it posible that i can/need to do this with OAuth?
Some example API gateways that can fill in my wishes will be great!
Amazon Api Gateway team here.
Our service supports native API keys which satisfy simple use cases. Are you interested in a simple mechanism to authenticate clients when they access your API? Some limitations would be that it's harder to manage a large number of keys, and there wouldn't really be any authorization to specific backend resources, only authentication to access the API in general.
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-api-keys.html
OAuth is better for dynamic user bases where new users register and you want to be able to control access for existing users over time. It is also useful when users have personal data that only they should be able to access.
Jack
I wish to create a single application registered with Google that uses Google's OAuth2 mechanisms to authorize read access to a user's Google Drive content. Then on behalf of that user I want to take that data and expose it via my application as a webservice (proprietary REST API). The webservice can then be consumed by arbitrary 3rd party applications that know nothing about the authorization of my application to access the user's Google Drive.
This is technically possible and not very difficult. My question is whether or not this is an acceptable use of Google's APIs and Google's OAuth2 offering?
OAuth 2 requires an user to affirmatively say yes to your request. As long as you properly describe what you'll do with it (and what is the nature of these third party apps) then I don't see why you can't.
If you just try to slip in the read scope on a generic-looking request form, than I would say that's a no-no.
In our company we run a number of different websites which are being tracked with Google Analytics (GA). Up to this point we have been using the Login protocol and GData to access GA data to display the data nicely on our custom web application dash boarded which we use for tracking traffic on our sites.
Nowadays Google has Google API Console which lets you track your API usage. We want to take advantage of this service to view howmuch APIs we consume. However from what we can understand it requires us to use OAuth for authentication instead of the username and password we currently use to access the data. We don't like OAuth because it redirects the user to Google for authentication when currently the user has no need to know about where the data is coming from and what credentials are needed.
Is there anyway that we could make Google API Console monitor our usage without having to switch from GData and the Login protocol?
You can switch to the OAuth 2 protocol and use a refresh token for offline access. Once you get the refresh token, you can save it to a file or database and use that to access the data without an authorization redirect.
See the docs here: https://developers.google.com/accounts/docs/OAuth2InstalledApp#refresh
Also see where there is discussion of using the refresh token: How can we access specific Google Analytics account data using API?