After reading the documents of Google API. I know that if a project we create needs to access private data, we should use oauth. But here is my situation. we will open a business account in Youtube, and we will create a project to push videos to our own account, we don't need to operate other user's' account. Can we use google youtube data api without OAuth?
There are two ways to access private user data with Google APIs.
Strait Oauth2. where you have a consent for asking the owner of the account if you can access it
Service accounts which are technically pre authorized by the developer.
Normally I would say because you are only accessing the one account that you own, use a service account. Unfortunately the YouTube API does not support service account authentication.
Due to the lack of service account support you will have to use Oauth2. I have done this in the past.
Authentication your script once, using a server sided language of some kind. The Authentication server will return to you a Refresh token. Refresh tokens can be used at any time to get a new access token. Access tokens are used to access Google APIs and are only valid for an hour. Save this refresh token someplace. You will then be able to allow access the YouTube account in question when ever you like.
Note: You will have to watch it. Refresh tokens can on rare occasion become invalid. I recommend having a script ready that will allow you to re authenticate the application again storing a new refresh token. Its rare that it happens but it can happen best to be pre-paired.
Oauth Play ground
Part of the point of Oauth is that it identifies your application to Google though the creation of your project on Google developer console. Things like quota and access to which APIs is controlled though that. If you spam the API they will know and shut you down. (never seen this happen)
When you request access of a user it pops up with the name of the project on google developer console. This is identified by the client id and client secrete for that project on google developer console. When I use oauth playground I get asked 'Google OAuth 2.0 Playground would like to ..'
So by using playground you are using Googles client id and client secrete to create a refresh token for yourself. If N other devs are also doing this the quota for YouTube may be used up in the course of a day. Also security wise you are now giving that project access to your data. Ignore that for a second what if google suddenly decides to remove change the client id or generate a new one. Your refresh token will no longer work. What if random dev X is using it as well and he starts spamming everything and the client id gets shut down (Think this happened last year) your going to have to wait for google to upload a new client id for the one that has now been banned.
Google OAuth 2.0 Playground might seam nice but its not for daily use IMO its good for testing nothing more. Create your own project and get your own access its not hard just requires a programing language that can handle a http Post.
My tutorial Google 3 legged oauth2 flow
Related
I have developed an express app that's purpose is to send emails. I authorized an email sender using googles oauth2 playground, and their google api. I wanted to use this strategy rather than working with a third party email sender to not be subject to vendor lock-in. I had the system working successfully, but after a day it stopped working with "invalid-grant". In production, I'd like to have a permanent email address (under their google workspace) that is solely dedicated to these bot emails. The oauthplayground says you can avoid the 24 hour expiration, but I recall doing that before and it eventually came up with invalid grant. Is there a better way to set up a bot like this? Or should I just try the oauth playground and using the config panel to avoid the refresh token expiration again?
To start with let me say that invalid-grant means that your refresh token is no longer valid. It is no longer valid because googles oauth2 playground is intended for use for testing purposes only.
Access tokens will expire in less than an hour and refresh tokens created using it will expire in 24 hours.
While it is possible to configure it to uses your personal client id and client secret it is still not the optimal way to go
Even using this method for production is not going to work well for you. If your app is still in testing phase then your refresh token is goin to expire in seven days. You will need to set your app to production in order to have a refresh token that does not expire.
The issue then becomes that in order to use the gmail api your going to need to have your application verified. You can not verify your application using the googles oauth2 playground as a redirect uri as you can not verify that you own this domain.
The solution to your problem is to create an application of your own hosted on your domain. This will allow you to create the credentials you need and have your app verified by google.
under their google workspace
You made one comment that is not clear. If you are using google workspace then why not just set up a service account with domain wide delegation to the user on the domain. You will avoid all the issues you are having above.
I have a mobile app using Azure AD B2C which works fine. I can create an account, login, forgot password etc. That's all fine.
The mobile app stores data on the device.
The mobile app should also be able to push data to a remote database and trigger various functions via a .net core web api.
The mobile app should only be able to do that if it authorises itself successfully with the api using the credentials, or access tokens, it has from the login.
I assumed that this could be implemented easily (because, why couldn't it be?)
But now, after weeks of searching, hours of video-watching, 10's of aborted [test] projects, & 1000's of user accounts; I'm not sure whether the thing I want to do is a thing that can be done or should be done.
Thoughts?
Yes, this is of course possible :)
You can check the code samples for some examples of how to do it: https://learn.microsoft.com/en-us/azure/active-directory-b2c/code-samples.
Your mobile app can acquire an access token for itself.
You'll have to define in B2C that your app contains an API, and then define the app ID URI (an identifier for the API, not a URL).
You can then define scopes that API exposes.
These can be different permissions that applications calling the API can have.
In your mobile app you then acquire an access token using those scopes.
This token can then be passed to HTTP requests to your API, which the API has to authenticate.
Do ask if you want to know about something specific.
I'm building an application that needs to have access to Google Drive and Google Sheets. I want the user to go to https://mydomain.appspot.com/authenticate to go through the Google login flow and authenticate themselves so that the backend receives access tokens for both Google Drive and Google Sheets.
After that I want the backend to be able to access Drive and Sheets without user interaction. For example, I would like a scheduled task to run every hour and retrieve some data from Drive and Sheets. I want the backend to use the token it received when the user authenticated themselves.
Is this possible? I really hope so. I have been looking here and I don't really find anything that can help me. https://developers.google.com/sheets/api/guides/authorizing
The backend is developed in Java and deployed on Google App Engine.
A long lived access token is actually called a refresh token. You will need to have your users authenticate your application then you will receive a refresh token. the refresh token can then be used to request a new access token from the Google authentication servers when ever you need.
Note: Do not get yourself side tracked with serviced accounts its not the same thing. You can run automated scripts using a refresh token gained from Oauth2, googles terminology is just a little confusing.
Check out the official google java client library it should handle most of it for you. Using OAuth 2.0 with the Google API Client Library for Java
You need to setup Offline Access as defined at:
https://developers.google.com/identity/protocols/OAuth2WebServer#offline
After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.
More of a theoretical question here - how can you get around using OAuth when you don't want to use it, but are using an API that requires it.
For example recently I was looking through the Bing Ads API and noticed they now require you to do OAuth as part of the process. Which makes sense if you're making an application that allows a user to control their Bing Ads account via your app. However, let's say you wanted all of your users to interact with one Bing Ads account.
Is it possible to hardcode all of the OAuth pieces in the background and just use the same authentication for every user to essentially send their stuff to the same Bing Ads account.
- If so, what sort of negative impacts would there be on that?
While it is simply not possible to get around using OAuth if the API requires it, OAuth can be used for more than just the "access delegated to client by current user" use case. As you suggest, if you want all users of your app to interact with your Bing account ("on your behalf" on OAuth speak), you can certainly do that with OAuth.
For an OAuth 2.0 implementation this would mean that you obtain an access token and preferably a refresh token in some way for your app, e.g. by you yourself going once through the Authorization Code flow (also, some services allow you to generate tokens in their web UI). Then you would "hard-configure" the token(s) in your app and use it/them to talk to the Bing API.
If a refresh token is included as well as an access token then your app can get a new access token in the backend whenever the old one expires without you (or your users) having to go through that initial flow again.
Be aware that this is not good practice for mobile apps, where you would have to distribute your app with the tokens embedded in the binary packages. Those tokens could easily be grabbed through hacking/scanning those binaries. But when the tokens are used in a backend service and never exposed in the front end, this is a perfectly valid scenario.
I'm trying to use OAuth with .NET (DotNetOpenAuth) to send updates to a Twitter account via a web application. I understand the basic workflow of OAuth and Twitter.
Where I'm confused if is it useful in a server web application? I don't want any user interaction.
But how it seems after an application start, the request token needs to be recreated and also an access token. This involves user interaction.
What is the correct workflow for my case?
Storing the request token or access token in config file?
Or the easist way, using HTTP basic authentication?
Thanks
If I understand you correctly your application will not be interacting with Twitter on behalf of your users but will be acting as the Twitter account for your application.
In this case there are 2 main factors to consider.
1) Do you want "from API" attached to each status as will be if you use basic auth or your applications name will happen if you use OAuth.
2) Do you want to put in the extra effort to implement OAuth.
If you decide to go with OAuth you would store your apps consumer key/secret and the accounts access token in configuration just like you would store the accounts screenname/password.
Your "request token needs to be recreated" phrase suggests you might be running into the problem where every time your user visits you need to re-authorize to Twitter, and perhaps you're looking for a way to access the user's Twitter account while he's not at your web site, and how can you do this when their token isn't fresh from being re-authorized. Is that right?
If so, the user isn't supposed to have to re-authorize Twitter every time they visit your site. The token is supposed to last a long time, which would also allow your site to access their Twitter account when they are not directly interacting with your web site. The problem may be that you haven't implemented the IConsumerTokenManager interface, but are instead using the default InMemoryTokenManager, which is for sample use only, since this memory-only token manager loses tokens every time the web app is restarted. Your own implementation of this simple interface should store and read the tokens out of some persistent storage such as a database.