I received an email last night regarding migration to the new Google Identity Services library. I was expecting client IDs for my apps to be shown on the email, but instead it showed applications that I do not recognise and client IDs that I cannot find in Google Cloud.
Where could these have come from?
My account is a super administrator of Google Workspace, so perhaps this could have been for an old employee of my company?
I would like a way to find the apps.
I have tried searching credentials for all my existing applications, but these apps or client ids cannot be found.
Related
I was searching for a simple way to link 2 or more project users just like google account for Youtube, Google Drive and Amazon account for amazon app & prime video app
On mobile these apps don't really require you to enter your credentials again but use the same account, without need of creating a new one as an account is already created by the user for another service from the same Provider/Company.
Is there any way to use Firebase / GCP to implement such functionality??
I also saw this thread, but it is using a third party identity provider called jumpCloud, is there any way I can build it from scratch?
https://medium.com/#tfalvo/single-sign-on-sso-for-your-firebase-app-with-saml-f67c71e0b4d6
Actually you would need to use The identity platform in tandem with Firebase.
Please also check the detailed answers provided on the Stackoverflow-link which is related to Implementing Cross Project User Auth (Single Sign On) like Google account using Firebase/ GCP.
It seems like there is already a Feature Request opened to have this feature implemented if the above two solutions are not applicable to your situation.
I have a sheets bound google apps script file that is triggered by the installable trigger onFormSubmit(), which was set up by me. The script, therefore, always runs with my data, no matter who fills out the google form which I am collecting data from.
As a part of this script, the Drive advanced API is utilized, and I create and edit teamdrives using this advanced service.
I want to be able to use the Drive Advanced Service, with all of its authentication management and autocomplete features, while using a service account.
I've seen from other questions on this topic that there are libraries for the management and use of service accounts within Google Apps Script, but they require managing authorization tokens and such of the users which the service account acts on behalf of, and using them to access the API. Going this route, I will have to use the HTTP Interface for the Drive API rather than the Advanced Service, which isn't optimal, but still doable.
Is there a way to authorize advanced services such as the Drive API for a service account acting on behalf of a particular user of my G suite organization in my scenario?
Thanks in advance!
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
I created a Actions on Google app with the Actions SDK. For this i used as said before the Actions SDK, firebase function for the fulfillment and firestore for storing data. All works fine.
Now i want to implement account linking to provide user specific information. I start to read the full documentation for account linking with the refers to integrate a Oauth 2.0 Server and soon. That is my first time i working with account linking and Oauth servers and now i'm totally confused. I don't understand where my auth server have to sit, how to setup it and what parameters it have to process. After reading more and searching for results i found that firebase provide Account authentication. Is it right that this firebase product is similar a Oauth server?
My next big problem is how to enabling account linking in my Actions app. In the Actions on Google documentation i found a topic how to expand the Action Package for account linking. My problem is to unterstand which information the probiertes need.
So summary, if the firebase authentication is really a Oauth server what i need to do that my app and firebase authentication works together.
Maybe everyone knows a good website for understanding the process of account linking and how it can be implemented.
UPDATE 1:
After getting the first answer for my question i started studying more about account linking and the authentication process.
After this i created following roadmap:
Create an website with a google account sing-in form and host it with firebase hosting
Set up the Oauth2 server
Interact with the linked account. Save account informations in my firestore database
So i started with step one. In the firebase authentication documentation i find a example for a google login form. After modifying and hosting the example i try it. It works fine. After sing in by using the hosted website, my google account linked with my project. I checked this in my google account settings. Also the example response with a lots of data like the profile name, email address and so on. So my question at this point is. Why do i have to set up a OAuth server now? After sign in with the example form i linked my account to my project successful. And so i can start saving the received data in my firebase database and act with them in my Actions app.
UPDATE 2:
Okay . Maybey i have a general problem of understanding the right use of account linking. I try to identify the user who use my action to offer special content when he comes back next time. Or maybe create a question with his name from his google account inside the question. So in my understanding i have to link the users google account with my action and save the account information in a database to identify the use next time. So is account linking for this task the right way?
No, Firebase Authentication is not an OAuth2 server.
Firebase Authentication provides a way for you to manage user accounts for your Firebase-based web or mobile app. With the Auth UI it gives a way for users to log into that account using a variety of means (including their Google account, Facebook account, or phone number). It does not, however, provide components that an OAuth2 server provides.
Most notably, it does not provide any way for a user to log in through another client (like the Google Assistant) to gain authorization for that client. You cannot, with Firebase Authentication, issue a token to the Assistant, nor accept a token from the Assistant and verify if this is a user inside Firebase Authentication.
You need to build these components yourself. Google describes the minimum tasks that it needs to do as part of this authentication. You can use Firebase Authentication as part of this as you build such a server (for example, it is a great way to have people log in to their account and for you to verify that account), and it is reasonable to use a Firebase Database to store user tokens if you go that route, Firebase Functions might be a useful place to implement the token exchange point, and Firebase Hosting would be good to host the login page itself - but you'd need to write code that "puts it all together".
Your auth server can sit anywhere. As I said - you can do it through Firebase Functions, but you don't have it. It just needs to be able to provide some responses through web URLs at HTTPS endpoints.
Once you have done this, you need to configure the endpoints on the actions console and implement a request for account linking in your code or in the action package.
Response to Update 1
After sing in by using the hosted website, my google account linked with my project. I checked this in my google account settings.
From an OAuth perspective - no, the Google Account is not "linked" to your project.
Google has issued a token to you (that is to say, the service that you've written) that gives your service access to certain resources. Those resources include information about a particular user.
This may sound like I'm splitting semantics, but it isn't. It is fundamental to what OAuth is offering and what it means when you get an issue a token. You currently have authorization to do certain things.
Why do i have to set up a OAuth server now? After sign in with the example form i linked my account to my project successful. And so i can start saving the received data in my firebase database and act with them in my Actions app.
You haven't linked your account. You have permission to do certain things.
Furthermore, aside from "that's how they do it", you need to setup an OAuth server because you now need to do the same thing for Google - give them permission to do specific things on your server (like use it). Normally this would be involved with "logging in".
Account Linking is really a fancy term for "logging in". You need a way for users to be able to log into your server. You have an access token, but that is roughly the equivalent of having logged into Google's server.
So why do so many websites, for example, have things like "Log In using Google" or "Log In using Facebook"? Because those sites are willing to trust that if their servers can get permitted to certain information at Google or Facebook, then they can trust you. And you might be willing to accept that when they login to your site (either through the web or through Actions), but the Assistant can't assume that. They need to make sure users actually log into your site - that user's deliberately want to do so and that you deliberately want to let them in.
I was previously using a cognitive search API key with no issues. Recently, it expired (I assume due a migration to Azure but it's unclear).
To get a new API key, I took the following steps:
created an Azure account added the Cognitive Search APIs service
(with image search, the service I'm interested in)
selected the
standard package (1k req/month at $3/month if I recall)
created the
service
When I attempt to use the new API key, either through curl,
my app, or the test console, I receive a 401. I recreated the service
and the new API key fails as well.
Thanks.
It's been a few months since you asked this question, but having just had this difficulty myself, I thought I'd share the solution.
If you create an instance of the service in Azure, you can presently create it on a whole host of different regions and it'll create successfully and provide you a key for it. However, if you look at the Azure Services by Region, you'll see that most of the Cognitive Services are only actually available in the West US region.
If you go back to the Azure portal, delete your instance and recreate it in the West US region, I expect you'll be more successful.