I wanted to know if GCP supports multi-factor authentication (MFA) or 2-Step Verification (2SV) for cloud API calls.
From this link: https://cloud.google.com/docs/authentication, I read the following:
"Google Cloud APIs only accept requests from registered applications, which are uniquely identifiable applications that present a credential at the time of the request. Requests from anonymous applications are rejected.
Application credentials provide the required information about the caller making a request to a Google Cloud API. Valid credential types include API keys, OAuth 2.0 client credentials, or service account keys."
However, it does not specify if I can use these factors simultaneously.
Thanks in advance,
Vijay
Related
I want to user Google Identity Platform as the CIAM solution for our GKE-based cloud service. We have a requirement to allow 3rd parties to access our cloud APIs using credentials they obtain via OAuth.
For example, our cloud service provides APIs that Google Assistant or Amazon Alexa can access on behalf of our users. Therefore, we want to provide an OAuth-based token manager that uses the identities of our customers as defined in the Google Identity Platform.
Is this type of OAuth service possible using Google Identity Platform, or the underlying Firebase service that drives it?
Based on the documentation for Google Assistant, you will need to implement your own OAuth2 endpoints. In the authorization code flow, you need two endpoints:
The authentication endpoint needs to sign in the user and get their permission to allow the third party (eg. Google) to call the customer's API on their behalf. If the user gives permission then they return an authorization code - which could be implemented by creating a custom token with Cloud Identity Platform.
Token exchange endpoint is also needed, which has two functions. The first is to exchange the authorization code created by the first endpoint for a refresh token and an ID token. The second is to exchange a refresh token for a new ID token. Both of these functions can be delegated to Cloud Identity Platform.
Additional note:
I would suggest to use custom claims to ensure that these tokens can only be used for the intended purposes, ie. to perform actions which the Google Assistant needs to do. Users shouldn't be allowed to perform other actions, eg. changing the user's password or providing authorization codes to other third parties.
Also make sure that this endpoint can't be used by malicious third parties. For example, you can check that the redirect URL provided matches what is expected, since this is where the authorization code will be sent to.
Currently, I am testing Google Cloud's Speech API and wondering how to pass dynamic Google Cloud API key to client app from server.
The speech function will be on client's app (React Native). Before every request to Google Cloud API or session, I am thinking to generate API key dynamically from server side (Nodejs) with a short lifetime and pass to client side. Only then, clients can use the Google service.
The main concern is that I do not want to embed Google Cloud API key on client app and I want to have control on which client can / cannot use the service. Is there a way to dynamically generate API keys on server side with short lifetime and pass to client? Thanks.
Update:
I was checking https://github.com/GoogleCloudPlatform/android-docs-samples/tree/master/speech/Speech and found the suggestion:
This Android app uses JSON credential file locally stored in the resources. You should not do this in your production app. Instead, you should set up your own backend server that authenticates app users. The server should delegate API calls from your client app. This way, you can enforce usage quota per user. Alternatively, you should get the access token on the server side, and supply client app with it. The access token will expire in a short while.
This is exactly what I want to do but can anyone suggest how can I achieve this? Thanks.
I am trying to find out how to get the API key for Step 2 on server backend side.
Never store credentials in users' browsers, luckily you are trying to adhere to this principle!
A setup that might be useful here has the following components:
Use an authentication mechanism in your client-side app, by means of an identity provider. You could use Okta, Auth0, Cognito, or any other authentication provider which supports Oauth2.
Use the same authentication provider to secure a custom-build endpoint, which could be a Google Cloud Function. This could be combined with Cloud Endpoints, but not necessarily.
In the same Cloud Function, after a user's identity is checked, you call the speech API.
The API key could be stored as a secret in Google Secret Manager.
The Cloud Function acts as a "serving hatch" to the API, passing back and forth requests from a user to the Google Cloud Speech API.
Your API key remains on the backend, stored as a secret. Users that are not authenticated using the authentication provider, will never have access to the Speech API.
I have created a service account on Google Cloud Platform. I am using a standalone Java program which uses GCP Java Client API to get the Authentication Token ID by taking service account JSON file. By using the Token ID, I can create a compute instance.
I don't want to use Java API or gcloud tool, is there a REST API exists which takes required details and return Token ID?
I went through the GCP documentation and could not find any details for the authentication and authorization through REST using Service Account.
I have created a service account on Google Cloud Platform. I am using
a standalone Java program which uses GCP Java Client API to get the
Authentication Token ID by taking service account JSON file. By using
the Token ID, I can create a compute instance.
Using a service account is the correct and recommended method to authenticate and authorize software applications.
Note. The assumption here is that the software application is running on your systems under your control. If instead you are installing software on a user's desktop or system not under your control, then you would use Google OAuth 2.0 (Google Accounts) to obtain User Credentials to authorize your application.
Another method is to issue short-lived temporary credentials from a service account credential that are time limited. These short-lived credentials are created on your server and then handed to the client.
I don't want to use Java API or gcloud tool, is there a REST API
exists which takes required details and return Token ID?
You have the classic "Chicken or Egg" situation. You need credentials to authenticate and authorize otherwise anyone could create credentials. Google Service Account credentials provides this. To create service account credentials, use the Google Cloud Console or gcloud CLI to download the service account Json file.
I went through the GCP documentation and could not find any details
for the authentication and authorization through REST using Service
Account.
This question is confusing. Do you want to use Service Account credentials to authorize your Google API calls OR do you want to call a Google API to obtain credentials?
In the first case, once you create service account credentials, they are used to authorize your API calls. You add the Access Token to the HTTP header when making API calls.
For the second case, use Google OAuth 2.0 to obtain credentials. Google OAuth 2.0 uses Google Accounts for authentication. This method provides you with an Access Token (just like a service account) and a Refresh Token and Client ID token. You will need to add the Google Accounts user identity to your Google Cloud IAM which provides for authorization (privileges).
I have a backend that is serving android clients, authenticating them with IdToken sent from the android app.
Now, I need to authenticate a service running on aws that is using my apis. So I figured a service account would do the trick, using the private pem file to create a IdToken and send it along just as the android clients do. But I find no way of obtaining an IdToken with these credentials. Is this possible (preferrably in nodejs).
Or am I on the wrong path here?
I know this is older, but I found this question and it didn't lead me to the answer I ended up with.
I followed the guide in https://cloud.google.com/endpoints/docs/openapi/service-account-authentication#using_a_google_id_token with some mix of https://cloud.google.com/iap/docs/authentication-howto, which mentioned that the key to this was to include a target_audience claim in the generated JWT.
So, essentially I made a JWT that looked like:
{
"exp": 1547576771,
"iat": 1547575906,
"aud":"https://www.googleapis.com/oauth2/v4/token",
"target_audience": "https://example.com/",
"iss": EMAIL OF SERVICE ACCOUNT
}
and posted that to https://www.googleapis.com/oauth2/v4/token with params grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer and assertion=<THE JWT>
Without target_audience the endpoint gave me an access token, but with it I got an id_token instead.
Grettings since 2020
I had problems in Java for take ID_TOKEN of a Google Service Account. My project had two years and i were using GoogleCredentials, fromStream method and a JSON credential, but this class didn't gave me ID_TOKEN, only access_token on a not JWT format.
I solved because on this years Google updated here java code for authentication, for take ID_TOKEN you must use this library https://github.com/googleapis/google-auth-library-java
<dependency>
<groupId>com.google.auth</groupId>
<artifactId>google-auth-library-credentials</artifactId>
<version>0.20.0</version>
</dependency>
And then use ServiceAccountCredential
String credPath = "/path/to/svc_account.json";
ServiceAccountCredentials sourceCredentials = ServiceAccountCredentials
.fromStream(new FileInputStream(credPath));
When you create this class, itself will authenticate with google and have a access_token,refreshToken...
For extract ID_TOKEN you must use this function:
String audience = "http://localhost"; //Your server domain
IdToken idToken = credential.idTokenWithAudience(audience, new ArrayList<IdTokenProvider.Option>());
String id_token = idToken.getTokenValue();
And with this you have a JWT token.
I hope this help people like me,that are trying get ID_TOKEN.
You cannot use service accounts generated for Google Cloud APIs to directly authenticate against your own APIs. How will you know which service account private keys are valid and which have been revoked? Google does not expose this information.
Service accounts are rather meant for delegation of credentials. When you access Google Cloud platform service, you will be authenticating with your google account credentials. You will not want to provision the very same credentials everywhere your running code needs to access any of the Google cloud services (i.e. Cloud APIs). Instead you create service accounts whose scope can be reduced to a subset of the scope of your google account credentials. This way a particular piece of code can be limited to only a few set of APIs.
Service Accounts
A service account is a special account that can be used by services
and applications running on your Google Compute Engine instance to
interact with other Google Cloud Platform APIs. Applications can use
service account credentials to authorize themselves to a set of APIs
and perform actions within the permissions granted to the service
account and virtual machine instance.
What are service accounts?
Service accounts authenticate applications running on your virtual
machine instances to other Google Cloud Platform services. For
example, if you write an application that reads and writes files on
Google Cloud Storage, it must first authenticate to the Google Cloud
Storage API. You can create a service account and grant the service
account access to the Cloud Storage API. Then, you would update your
application code to pass the service account credentials to the Cloud
Storage API. In this way, your application authenticates seamlessly to
the API without embedding any secret keys or user credentials in your
instance, image, or application code.
I know where your confusion stems, it is because service account also have the same OAuth model you are used to.
You can use service accounts to get access tokens and refresh them as needed, but the scope of authentication is at the very maximum limited to the surface of the Google Cloud APIs. You will not be able to mix and match your APIs with that.
Alternative is to either build your own authentication model (which is not so clear from your question when you say authenticating them with IdToken sent from the android app) or rely on something like Cloud endpoints which you create and manage APIs along with API keys for authentication.
As you already mentioned in one of your comments, you can follow the Service-to-Service authentication guide which describes how you can use Google Cloud Service accounts to authenticate with your APIs running on Google Cloud Endpoint.
It supports using Google ID JWT tokens. The caller will have to send the JWT to Google Token endpoints to obtain a Google ID token and then use this Google ID token in all of your requests. This approach also has the advantage that you only have to whitelist the Google ID token server in your API configuration.
I am trying to obtain data from a web service (publisher).
The web service lets me send the data (message) to any url through a webhook. My plan is to send it to a Google Pub/Sub topic.
However, Google Pub/Sub is not recognizing this third-party web service. It is returning a http 401 response code, meaning that the web service is not authenticated.
My question is, How can I authenticate it?
Authentication for requests made to Google Cloud Pub/Sub or any other of the Google Cloud Platform services can be accomplished in a couple of different ways. In your case, where you want to make a direct request via the REST API, you'll need to create a service account and authenticate via OAuth 2.0. The Using OAuth 2.0 for Server to Server Applications guide details the process. If the web service you are using supports OAuth 2.0 authentication for requests it makes, then you should basically be set. If it does not, then you will have to take care of acquiring access tokens (and acquiring new ones when they expire) manually.