I needed to access a Google's service, i.e. Google Analytics, from my Symfony 2 application, so I had to use the Google api client (version 2). Before accessing Google Analytics' info, I had to create either a api key, a client id or a service account in the Google API Console.
At the end, I created a service account, and a file was downloaded. This file is used by the Google api client to grant access to my Google Analytics account and its respective collected info.
My question are:
What are the differences between api key, client id and service account?
When to create/use one over the other, and why?
I've not seen any exhaustive article which explains what I'm asking in this question.
This thread is old, but still adding the information. Might help others in future.
Google needs unique identifier to tie it to your project (with your android package) for authentication and to manage traffic or quotas.
Oauth and API key are such unique identifiers.
OAuth 2.0 client IDs: If your application is using OAuth 2.0 protocol, then use OAuth client ID.
OAuth is used to create the Access token, which in turn is a unique identifier. However, the user needs to agree a consent.
https://developers.google.com/identity/protocols/OAuth2
API keys: An API key is a unique identifier that you generate using the console. The advantage is the user does not require an user action or consent. But you cannot use the API key for authorization unlike OAuth. Use an API key when the data you want is public and does not need a user authentication, such as Google maps.
Service Account : Google APIs such as the Prediction API and Google Cloud Storage can act on behalf of your application without accessing user information. In these situations your application needs to prove its own identity to the API, but no user consent is necessary. Similarly, in enterprise scenarios, your application can request delegated access to some resources.
For these types of server-to-server interactions you need a service account.
https://developers.google.com/identity/protocols/OAuth2#serviceaccount
The API keys authenticate for APIs that do not access personal data.
The client id authenticates with your Google Account.
The service account authenticates your application when you do not want to use the login data of your own account (or any real persons account).
You still need to add the service account to any Google service you want to access with that service account.
Related
I'm building a multi tenant Service Fabric Application, that allows a tenant to specify a login type - Identity(asp.net)/Azure AD.
I have an Authentication service that checks to which tenant the user is linked to and then proceeds to check if the username:password for the user is valid, if valid it returns a JWT token to the gateway API/web API that then allows access to the rest of the services on the cluster.
This is further secured by roles to limit actions and data access etc.
Question 1
What would be a secure way to save the app id and secret given by that tenant if they use azure AD?
In my DB and encrypt the info, it would have to be decrypted to connect to the AD(Trying to keep in dynamic).
Question 2
I'm implementing my own sliding refresh tokens to obtain a new JWT after it expires, is there a better/standard approach?
Question 3
Is there a better/standard way to handle this multi-tenant sign in process.
Question 4
Is there a way to have optional claims set on the JWT Subject that would allow access to shared services but prevent access to tenant specific services if the claim value is incorrect?
Edit
Ideally the Roles should not be part of the tenants AD/B2C because they role are dynamic and managed from within the application.
Instead of building your own STS logic, have a look at IdentityServer, a popular and great OSS tool.
For example, have a look here for a multi-tenant example using asp.net core.
It supports adding custom claims to the token, by implementing a Profile Service. Services can be configured to use claims for authorization.
This blog post may also be useful.
I will very strongly advise you ride upon the Azure tenant model and let Azure AD manage all credentials and authentication. In today's world its a very bad idea to store and manage user credentials when there are plenty of Identity Providers available.
Recommended reading:
How to build a multi-tenant app with Azure AD
How to secure a Web API with Azure AD.
Libraries like MSAL.NET will automatically manage token caches and refreshes.
Use roles and groups in Azure AD
Claims in tokens issued can be customized to some extent.
disclaimer: I work for Microsoft
I'm trying to verify an app that manages a user's Firestore collections using Google Cloud APIs.
After submitting for verification, I received this email from the API dev team:
Dear Developer,
Thank you for submitting an OAuth App Verification request for the following Cloud scopes:
https://www.googleapis.com/auth/cloud-platform.read-only
https://www.googleapis.com/auth/cloud-platform
Three-legged OAuth2 scope grants are intended for human users to grant access to all of their data hosted on a particular API. Access to your requested OAuth2 scopes would provide overly broad access for Google Cloud Platform customers. Google Cloud Platform only supports grants to specific resources for specific users/services, with access controlled using Cloud IAM Policies.
Follow the instructions below to gain access to the Cloud scopes you requested:
Create a service account to represent your service and to access data from your users’ Google Cloud Platform project
Instruct your customers to grant your service account appropriate access to their Cloud data via IAM Policies
Note that you may want to create a service account for each customer to avoid confused deputy problems.
I already have 3 service accounts (I think they were created automatically by GCP or Firebase), but I'm having trouble understanding what the second point is and what action should I take.
The app makes requests from the client using my Firebase API Key to read and write on Firestore collections on the users' behalf. These are the scopes I'm using:
email
profile
openid
../auth/cloud-platform.read-only
../auth/cloud-platform
I expect the app verification process to complete successfully so the users don't see the "Unverified application" screen when logging in.
You are trying to grant yourself access to a customer's account/data using your Project's OAuth Client ID. This is very dangerous as you can receive an Identity Token and Refresh Token that can make it difficult for a customer to revoke your Access Token. Most customers/developers do not know how to do this.
Google is tightening the level of access that you can request. You have asked for permissions that are too privileged. The correct approach is for the customer to grant you access to their account via Google Cloud IAM. These privileges can be to a service account created by your Google account or to your Google Account email address. Both methods require the customer to grant permissions in their GCP account using IAM.
Your problem can be solved in three steps:
1) Delete the following scopes as Google will not approve your app with them without an audit.
cloud-platform.read-only
cloud-platform
Note: If you only require access to a very specific service, change the scope for that service. You might not get approved.
2) Create a service account in your Google Cloud Platform account. Provide the email address of your service account to each customer. They will need to add the email address to the Google Cloud Platform console under the IAM section and assign the required IAM permissions.
Note: You may want to create one service account per customer for better security, separation, and logging.
3) Use the service account instead of a Client Application.
Note: If you require Google Console access to your client's Google Cloud Platform account, provide them with your Google Account email address. They can assign your email address the required permissions to access the console for their project.
I'm creating an app that will run on the Google Assistant which should use firebase authentication to authenticate the user and then perform some user specific stuff.
It isn't currently possible for a user's Assistant account to automatically be linked to a Firebase Authentication account. You can create a basic OAuth2 server that uses Firebase Authentication to identify them as part of the Assistant Account Linking procedure, but this isn't done automatically. Once they have done the account linking, your Action will get an auth token (that your OAuth2 server has issued) and can use this to get a valid token to work with Firebase on their behalf.
Google doesn't typically announce future plans, however there have been a number of requests for similar features.
I'm working on a Google home application using an external API. I need the current user to be logged in and linked with the external API (access/refresh token provided by the external API).
My approach:
Setting up a firebase application
The google home app lives within the functions folder.
I would set up a page where the user would first sign in with his Google account using firebase.auth(), then his external API account (using the external API Oauth).
I would then create an entry in the firebase database to store, for each user, an access/refresh token provided by the external API.
This is where I'm a little confused and stuck. I've managed to setup the sign-in page (Google sign-in, then External API Sign-in) and store it the the firebase database (/users/{google_uid}).
Now that it's in the database, how do I set up the authentification in the Google home app?
Thank you!
First, you need to have a project in console.developers.google.com and activate the Google Actions API in your project. Then, you should follow these steps:
Whitelist the following redirect URI in your API:
https://oauth-redirect.googleusercontent.com/r/
In your API.AI project go to Integrations and enable the Actions on
Google Card.
In the setting of the Actions on Google, place your project ID and
select Sign in required for the welcome intent and any other
intent the user needs credentials.
Below, you will find the OAuth2 fields, like clientID, client
secret, authorization URL and token URL. Fulfill it with the OAuth2
information of your API and Authorize the application.
After you authorize, you can Preview the application and it will be available in your Google Home device, and when you invoke for the first time, it will provide a card in your Google Home app to do the linking. If you don`t have a device, there is a Web Simulator where you can test your Action.
For more information access the actions on google documentation.
There are a few issues with how you're thinking about account linking with Actions On Google and Google Home. Google Home doesn't give you direct access to the Google account - instead, it acts like a web browser and the account linking process requires you to issue an OAuth2 token to the Home "browser" for it to use in the future.
If you have control over the external API, and it issues OAuth2 tokens (which it sounds like it does), you can skip the Firebase portion completely. You just need to configure API.AI with the OAuth2 information for this external service - the client ID and secret, the URL for the login page and for the token exchange page, etc. In this case, your webhooks will be called providing the OAUth2 access token that you should pass on to the external API when you're calling it. The details are in the Actions for Google documentation Account Linking documentation.
If you do not have control over this API, you may need to provide a basic implementation of an OAuth2 server that can hand out auth tokens (either ones you create or ones that can be used to get the auth tokens from the external API). Your webhooks will then be called with these OAuth tokens, and you should use the token to find the token to use to access the external API. You have some options to implement this, and these options are discussed at OAuth2 Account Linking Overview in the Actions for Google docs.
I have a Web API and an Azure Web App that access the same database. This database has all user information. I'm using ASP.NET Identity for user management. I'm having an issue where when a user is created by the web app the Web API requires a restart, or at least a relatively long while before the user becomes authenticated by it. This, of course, is entirely impractical. How can I update the environment immediately on the Web API so that the user can access their resources?
UPDATE 3:
Turns out it WAS authenticating with the API, but I didn't hold the correct claims because my user was not associated with a Google account. See Answer below.
Wow. Nevermind. We require Google accounts to sign on one kind of client, and we SHOULD require it on the web client, but I haven't set that up yet. If an account is set up without an associated Google account, AND that email has a Google account set up on the client then it will try to authenticate with those Google claims that don't exist in the DB. So while I CAN authenticate with that claim through the Google SSO, there are no claims set up in the DB, resulting in 401 errors. Authenticated, but unauthorized.
This means my auth filter is probably misconfigured because it should not authenticate with Google if my account does not have an associated Google account, no matter what my client requests. It also means that I need to refactor my SPA on my Web App that statically calls for Google authentication with the API.