I'm trying to test connecting to a Google API on behalf of different Google accounts from the same Google Cloud Project.
I tried using different OAuth client IDs in the OAuth 2.0 as different environmental values but that's not working.
It seems the built-in web browser auto-authorizes for the last Google user who was signed in.
Is there a way for me to force Paw to redo the OAuth user flow?
Related
I have a .Net core web Api calling google drive api. The google drive api should authenticate the api call with Okta and authorize. How can this be achieved?
Should i setup the auth application in Okta dashboard and generate client id and authentication token?
Which before calling google api will be used to get bearer token from Okta and shared with the google api?
Will be registered with google admin console and generate the tokens?
The domain of the api will be google.api.com ... so no where it is going to Okta for authentication
What you do with your Okta site will be after you have gained access to the google api on behalf of your users. a bearer token from Okta will not grant you access to a google api you need to go though googles authorization server to get that.
In order to access the Google Drive api and access private user data. The owner of that data will need to authorize your access.
To do this we use something called Oauth2. The issue you will have is begin that you say you are using a web api to call Google you will need to create a web application on the side where your users can authorize your application to access their data. You will need to register your application with google on Google Developer console. Create a web client credentials. Then when the user has authorized your application to access their data you will will need to store the refresh token in your system associated with the user.
Then your web api will be able to access the users data by loading the refresh token and requesting a new access token.
There is currently only one sample web-applications-asp.net-core-3 for .net core web applications it doesn't show how to store the refresh token you will need to work that out.
I do have a video on setting up asp .net core with the google people api it might give you a starting point How to get a Google users profile information, with C#. as well as one on how to create a How to create Google Oauth2 web application credentials in 2021.
I am writing a google drive desktop application and I am using OAuth 2 to get credentials. I can get creds for just reading, but not changing files. As it is a desktop application, there is no site. It is written in https://developers.google.com/identity/protocols/oauth2/native-app, that I need to "supply a local redirect URI to handle responses from Google's authorization server". So, should the client also be a server and listening on some port locally? If I want to have the app verified, I need to provide Authorized domains and other stuff, but it is a desktop application, again. Or maybe there is a way to allow users to use the app, but with a warning on a consent screen for example for development purposes.
Also how to hide the credentials, that I use to get the token? If I publish the app with the credentials, everybody can just steal them and use them
In order to develop a desktop application which will use the Drive API you will have to use credentials of the web app type for which you will later provide the appropriate redirect URI.
By using OAuth 2.0 in your application, you are the only one who has access to the credentials for the application - unless you share them.
According to the Google OAuth 2.0 documentation:
You start by obtaining the OAuth 2.0 client credentials from the Google API Console. Then your client application requests an access token from the Google Authorization Server, extracts a token from the response, and sends the token to the Google API that you want to access.
For the login process, when the users will log-in to your application, they will use their own credentials and then they will have to authorize the application you have built in order to be able to use the Drive API.
Reference
OAuth 2.0 for Mobile & Desktop Apps;
Using OAuth 2.0 to Access Google APIs;
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 am evaluating the possible options provided by Google for adding google signin in my web application. The possible options as i see are
Google+ Signin
OAuth2.0
OpenID Connect ( OAuth2.0 for Login )
I didnt go with 1st one as it limits the API calls i can make in a day to 10000
Out of 2 & 3, i am inclined to go for 3rd. I dont really need API authorization and i am not concerned about access token expiration in my case. Once i receive user profile from Google, my web app will manage its own session of the user and does not need to query Google for any other data related to the user. And as per Google documentation, #3 allows me to customize User consent screen, while 1 & 2 dont.
Any comments on my comparison between 2 & 3 ?
In fact 2. is comprised of a Google specific usage/extension of OAuth 2.0 to establish user identity on top of the authorization provided by core OAuth 2.0. Using 2. you would have to ensure that you only receive the access token in a code flow and you would have to perform a Google specific introspection call to find out who the user is, where the user's identity is returned in Google specific claims.
On the other hand,3. is a standardized way to login users through a 3rd-party provider so it is a future safe choice for which you'll find more support in libraries/sdk's (well at least in the near future).
How do I get my application to work with the Google APIs for both Google Apps Marketplace and non-Apps Google Account users using OpenID and Oauth? (AuthSub is no longer supported by Google Apps)
Error I have experienced:
Token invalid - Invalid token: ACL not found for domain: 358xxxxxxxxx and consumer: 736xxxxxxxxx
Solution:
I had to learn to wrap my head around Google Marketplace. I created 3 apps (dev/localhost, staging, live) and reference the necessary keys. This error was because I was using the wrong key with the domain.
Your OAUTH consumer key and secret will only work for Google Apps domains combined with 2-legged OAUTH. That is because - at installation time - the domain administrator of the GAPPS domain authorizes your consumer key and secret for all users within his GAPPS domain.
If you want to ordinary Google accounts to work, then you need to use 3-Legged OAUTH and individual users need to authorize access to their data for your application. This means you have to initiate an authorization flow and store token and token secret per individual user and use these tokens each time you want to access an individual's data.