My app registers a subdomain for every new customer. It is also using Google oauth to authenticate users. Which means that for every new subdomain there must be a corresponding "allowed origin/redirect url" record.
I can add it manually in the developer console, but is there a way to do it via an api call?
This of course wouldn't be a problem if google allowed wildcard urls for origins.
Related
The goal of the steps below is to create a custom oath client ID which will be used only for my instance of rclone. rclone already is registered as an app with google API with it's own set of client ID credentials, but the recommended way is create another set for the sake of performance.
In the google api developers console I create a new project called my-rclone-project.
Once the project is created I proceed to the OAuth consent screen where I choose the type External. As I proceed to the OAuth consent screen there is a setting paragraps called Scopes for Google APIs. Here I leave the default scopes (email, profile, openid) explicitly not selecting the scopes which would allow access to google drive.
I call the application my-rclone-app and use the defaults.
After that I go to the Credentials screen and do CREARTE CREDENTIALS -> OAuth client ID.
I choose the Desktop app and name the client my-rclone-desktop-client. Finishing this results in the reation of the Client ID and Client secret. Given the scope selected in the OAuth consent screen i would expect that these credentials won't allow the app to ask permision for anything besides what was defined in the scope. So it shouln't be able to ask for permission to access the google drive APIs.
I than proceed to configure the rclone from my pc rclone config. I enter the oauth credentials I created in the step above. During the config process I'm asked to define the scope to use when accessing google drive as if the OAuth consent screen isn't relevant at all. As the config nears it's end, I'm redirected to the browser where the app is requesting to See and download all your Google Drive files. I accept that end end the config with defaults selected.
As I try listing with ./rclone lsd google-drive: I get an error about the drive API not being enabled with a link in the error on how to enable it. Going on that link and enabling it results in ./rclone lsd google-drive: listing the content of my drive.
What is the purpose of having to define an OAuth consent screen and the API scope as a part of it when the app can request an arbitrary scope completly bypassing the scope selected in the OAuth consent screen setup?
Reference: Create a client ID in google API
Why you want to have custom OAuth consent page?
In order for you app to use one of Google's auth servers, your application needs some way to be identified by auth servers and that is where Client ID and Client Secret comes in to play and consent page server as a screen on which you application specific information such as application name, contact info, privacy policy, term of use etc. will be displayed to the user.
What are scopes that you define on consent screen setup?
On consent screen set up you are supposed to include all possible scopes that you application is going to request from Google APIs, but that doesn't mean you app is limited to those scopes only. Scope listed here will be used by Google for application verification purpose and once Google verifies you application, it will no longer display This app isn't verified warning page as long as your app is requesting one of those verified scopes.
Even after verification, if you application completes verification, requesting any scope access which isn't included in this list will still display This app isn't verified warning message.
and clicking on learn more link will open Google Account help page which clearly states once you provide access to application, when you allow third-party apps to access your Google Account, they can copy and save your data on their own servers. Because Google can’t protect the data on another company’s servers, your data may be subject to greater data security and privacy risks.
What is the purpose of having to define an OAuth consent screen and the API scope as a part of it when the app can request an arbitrary scope completely bypassing the scope selected in the OAuth consent screen setup?
The main purpose of the consent screen configuration is to allow app developer to present information about application it's terms and privacy policy during authorization process. And of course not to have warning once application is verified.
Please refer following link to better understand about unverified apps and scope verification:
https://support.google.com/cloud/answer/7454865?hl=en
https://support.google.com/cloud/answer/9110914
https://www.gmass.co/blog/five-annoying-issues-google-oauth-scope-verification/
https://support.google.com/accounts/answer/3466521?p=app_notverified&visit_id=637365968258169095-220403864&rd=2#notverified
I'm trying to setup account linking in dialogflow agent using this documentation, I've created my credentials from the Google cloud platform. when I'm trying to put that credentials data to Actions on Google console, it gives an error as shown in below picture.
I've put these Authorization URL and token URL from my credential JSON.
The error says: Google accounts cannot be used as Auth endpoint urls per our Account Linking policyLearn more
I want to know about the following:
What this error means.
how to solve this issue.
The error is exactly what it says - if you are setting up Account Linking using the Auth Code Flow, you're not allowed to use Google's servers as your authentication endpoints. You're expected to have your own OAuth server (or use one such as Auth0) to do this.
How to resolve this depends on your exact needs and exactly what you have available to work with:
Setting up your own OAuth server
If you have an existing service that has accounts already, you would likely want to link the user's account in your service to their Assistant account.
To do this, you would need to setup an OAuth server. If you are already using one as part of your existing service, you can configure it for the Assistant. If not, Google provides information about the minimal implementation requirements or you can use existing libraries.
Using OAuth as a Service
You can also use a service such as Auth0 to provide authentication. Depending on your needs, this is a good service that allows people to log in using a range of providers and gives you an API to access their accounts maintained on Auth0.
Using Google Sign-In for Assistant
Finally, if you are either using their Google Account in your own service, or you just want a way for them to log in using their Google Account, you can use the (still in preview) Google Sign-In for Assistant. This will give you an ID token as part of your fulfullment which contains the Google ID
I have developed and deployed an app that requires OAuth (Google, Microsoft) to sign in. Due to some reasons, I now want to change my domain. I have the following questions
If I change to new domain, do I need to create new client id and secret?
If I change the Redirect URL to point to new domain, will the existing users who have already given permission for this app to read/write emails need to authorize again?
This question is applicable to both Google and Microsoft OAuth client id.
I'm making an application wich allows the admin to manage the files of users in the google apps domain.
Since the docList api is deprecated I used the Drive api.
How I can create a Drive service as another user while logged in as admin?
Some people suggested to use the OAuth consumer key.
But I don't know how to implement this with oauth-2.0.
You might want to check out this post: Google Drive service account returns 403 usageLimits
I used OAuth2 and a service account to accomplish pretty much the same. Keep in mind you need to use the API Console to setup your environment and ensure the service account is added to the Google Apps domain with the proper scopes to allow access.
I am trying to support "Hybrid" Federated Login and oAuth2 (using logic from this document) for a webservice which will:
support Sign in using your Google account on my site. That is, from the documentation: You can also choose to use Google's authentication system as a way to outsource user authentication for your application. This can remove the need to create, maintain, and secure a username and password store.
Access the user's Google Analytics.
Here are the steps I have done.
I form my request to https://accounts.google.com/o/oauth2/auth with the scopes (Google Analytics) I want access to.
I Get redirected to google where it has my icon and which scopes I am requesting access to. I grant access.
I get redirected back to the callback page.
I get the tokens (access and refresh), as well as a huge id_token string (which I don't know) and store all of this information in my database.
I then make a call to https://www.googleapis.com/oauth2/v1/userinfo?access_token=xxxyyyzzz to get the user's email and name and store this information in my database too. I also notice it returns a id field which to my knowledge never changes and I presume is some sort of unique identifier. I store this too.
Question: If I go to Authorized Access to your Google Account section in my Google account, it shows that my site has access to "Google Analytics. BUT, it does not say Sign in using your Google account. This is what I am trying to accomplish. I would have thought using the logic would enable Sign in using your Google account. What am I doing wrong? And what would be the applicable call to google so that users can sign in to my site?
If your site has access to something like your Contacts or Analytics using OAuth, you'll never see "Sign in using your Google account". I'm pretty sure that's only if you use OpenID (not OAuth) only for sign-in.
Specifically, OAuth is used for giving you access to APIs to create/update/delete data, while OpenID is for signing in.
If you are asking how to identify user for future logins, you have two options:
Mix OAuth with OpenID, that is called Hybrid. I have described it on this answer.
Use userinfo scope and request userinfo (email, etc.) after successful OAuth authorization. It is described on Google OAuth 2 documentation.
If you mean automatically login to your web site in future visits you can use OpenID "immediate mode" (openid.mode parameter).
When the user is redirected back, you call the second request from your own (server-side?) code, and get their email address. When you successfully get it, that means that the user is logged on. You can add it to the session (e.g. as cookie), and as long as you have it, the user is logged on. You make the user log out by forgetting the email address, so by clearing the session/cookies.
Add this paramter to the https://accounts.google.com/o/oauth2/auth URL call: approval_prompt=force and then the Sign in using your Google account will always show regardless of whether the user was already signed into that or any other account.
So the call would be like this https://accounts.google.com/o/oauth2/auth?client_id=<client id>&redirect_uri=<uri>&scope=<scope>&access_type=<online or offline>&response_type=code&approval_prompt=force