I have a .NET console application that performs operations on files. I would like to allow clients to give us access to their Google Drive accounts so we can read and write files. Our console application runs as a service so there is no way for the user to interact with it and authorize our access to their Google Drive account.
I was looking at using a Google Service Account for application level authentication until I learned that a Service Account does not have access to the Google Drive folder of the user that sets up the Service Account. This sort of defeats the purpose because it is the client's Google Drive account I am looking to gain access to.
I saw a workaround posted by SO member #pinoyyid posted in this SO answer where the refresh token can be generated using Google's Oauth2 Playground, but I am concerned that the refresh tokens could expire and user intervention would be needed again to generate another one.
Another response mentioned the solution was to create the Service Account and then share the user's Google Drive account with the Service Account.
What is the recommended approach by Google? How best to gain access to a Google Drive account while only requiring the owner to authenticate on a one-time basis, yet allowing them the ability to revoke access at any time?
Both Service Account and a stored OAuth Refresh Token are viable approaches. Each has its pros and cons.
A Service Account will work where your users only need to grant access to a specific folder which they can share to the SA. Be aware that any files the SA creates are owned by, and consume quota of, the SA. You can't "share the user's Drive account to the SA", you can only share individual folders.
Storing a RT is the more permissive option. You wouldn't use the OAuth playground as described in my answer that you referenced as that's far to clunky to ask users to go through. Instead you would need to write your own registration/authorisation service (you can use AppEngine, Lambda, etc - so it's not difficult to write and host).
Related
One friend of mine subscribed to Google one and granted permission to me use the storage, the problem is when i'm using a service account to upload a file to google drive, the storage shows as 15GB and don't let me upload more than that, is there anyway to grant the storage from my account to the service account?
I couldn't find anything related to Google one, any direction would help.
Edit: I used OAuth2, it isn't the best alternative, but I really don't want to go more into this.
Service accounts are dummy users they have their own drive account but there is no way to extend the allotted space to that account.
Storage is based upon an account. If you want to use the storage of a standard gmail user with a service account. Then the service account needs to be uploading to that drive account.
Have your friend share a directory on their drive account with the service account. Then when you upload files make sure to set the parents id to that of the folder your uploading to.
I developed a desktop application that saves projects locally to disk. Each project is a directory that consists out of many files. If certain files are missing the project is corrupt.
I want to add Google Drive support to my desktop application, so the user can load and save projects directly to the cloud. For clarification, the desktop application talks directly to the users Google Drive. There is no 3rd-party webservice involved.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
My question is, can I create a Google Drive App that shows up in the market place, that my desktop application can use to access the files on the users drive? Or is the market place meant to be only for 3rd party web-services that can access someones account?
TLDR; I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
First off an API key is only used to access public data. You will need to have your user authorize your application access their google drive account using Oauth2.
You will need to create a project on google cloud console and create Oauth2 credentials which will allow your application to request access of the user.
I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
Its not exactly one click but a user will have to be signed in to their google account and then click the authorize button.
I am writing a server side python script with Pydrive which needs to store a file in a specific gdrive. Pydrive and this post suggest to use a service account.
However this would mean that with the credentials of this service account all gdrives are accessible and I would rather avoid that.
Ideal only one specific gdrive or all gdrives where one specific user has access to should be accessible.
Is it possible to give programmatically access to only one specific gdrive?
[Edit]
As mentioned in the comments I am apparently not looking for a OAuth flow.
I am looking for a server-to-server communication for accessing one specific google drive using the principle of least privilege access. Doing this with a service account + domain wide delegate and google drive r/w scope would mean that with this service account all google drives can be accessed which is not what I want.
Unfortunately there is a domain wide policy in place which forbids to share google drives to "other" domains. This means I can not use a service account without domain wide delegation and just share the drive with it.
I don't understand what you mean by "programmatically", when you already tag the question as oAuth - asking for oAuth2 flow, which is interactive. When there is nobody, who would press the buttons, this probably isn't the authentication flow you're looking for. Just share a directory with a service-account; no domain-wide delegation is required (with that enabled, there would be no need to share it).
One could even abstract the whole Drive API access credentials away by using a simple Cloud Function, which has to task to update one file; triggered through HTTP, utilizing the Drive API.
Possible approach - dummy account
You could designate a new account that will be your "service account". In reality it won't be an actual service account, it will just be a dummy account that you can call something like "gdrivebot#yourdomain.com". Then you can share only what is absolutely necessary with it. I think this would be the only way to get that level of fine-grained control that you are looking for. This would require your admin to designate a new account just for this purpose though.
Google APIs can have usage limits, both on a per-user and a per-application basis. For example, the GMail API free tier is limited to a billion daily quota units across all users of your application.
This works for well-designed server-side applications, which can centrally ensure they obey these usage limits. However, I’m not sure how this is supposed to work for client-side apps. As Google’s documentation says,
Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets.
These apps are still supposed to use a client_secret and credentials, but these are assumed to not be confidential despite the name. However, just saying they aren’t secret doesn’t prevent abuse; a user of the app can take the credentials file and use it for a different purpose, perhaps one that uses the APIs more. What can an application developer do to prevent people doing this from burning through all the available quota?
Edit for clarification:
The use case that prompted this is a purely desktop app that doesn’t connect to any service except GMail (see https://github.com/mbrt/gmailctl/issues/48). If it weren’t for a global quota for all users of the app, there would be no reason to worry about individual users at all; they don’t connect to any service except GMail itself.
You could write a server app (a Cloud Function would work) which holds the secrets. Clients call your endpoint with some form of identifier and you return an Access Token. If your users have a browser, they can auth each time; if not you would need to request a Refresh Token which you store and use that to generate an AT.
I am developing an app to manage room bookings via Microsoft Graph. In the end, the app needs to read and cancel meetings that are booked into a certain room resource account.
Unfortunately, there is only the permission Calendars.ReadWrite which gives the app permissions to read and write every users calendar in the tenant, including private appointments.
I have not found any possibility to restrict the permissions or specify them more granular.
Does anyone know how to deal with this? (Or do I have to fall back again to service accounts and the old exchange web services, where I can give granular permissions to that service account?)
Thanks a lot in advance!
Application permissions imply the full the level of privileges of that scope, referenced here.
If you are scoping this specific mailboxes/calendars, you use delegated permissions with a functional account that has delegated permissions on those resources. We've had to do that before. It sucks, but that is the nature of App Permissions versus Delegate.
If you have are trying to script this, you could try the "client_secret_post" authentication method for the token acquisition mentioned here and in more detail with the OpenID Connect Spec and the OAuth 2.0 Spec.
You can now restrict the calendar/mailbox access an app will have using the New-ApplicationAccessPolicy PowerShell cmdlet. Using this you set the application up to use application permissions and then create an application access policy to limit the scope of these permissions.
There's an easy to follow guide on MS docs on how to set this up:
MS docs limit mailbox access