I’m working on a web app using Google App Engine and running into a permissions issue with the Drive API.
Here’s my current workflow:
User logs in and I get authorization for the drive.file scope
My app creates a new file using a service account that belongs to the application
The file gets shared with the logged-in user with write permissions
The problem happens when the user tries to modify the shared file through my application. I keep getting this error:
403: The authenticated user has not granted the app {appId} access to the file {fileId}
This is confusing because my application created the file originally and still owns it. Why does the user need to grant access to something my app already controls?
What I want is for users to be able to edit these shared files while keeping proper attribution showing they made the changes. Right now my only options seem to be requesting broader drive scope permissions, using the Drive picker UI, or having all edits go through the service account which loses the user attribution.
Has anyone found a better way to handle this scenario?
Had this exact nightmare last year! You can’t mix user tokens with service account files - gotta use the service account for ALL file operations. Set up a middleware layer that catches user edits and routes them through your service account, then log who made the changes on your end.
This happens because Google’s security model ties user tokens to specific files with the drive.file scope, even if your service account created the file. The service account ownership doesn’t automatically give user tokens the right permissions. I ran into this same problem building a document management system. Here’s what worked: skip direct user API calls and use service account impersonation instead. Here’s how: when users want to edit something, capture their input on your backend, then make the actual Drive API calls with your service account credentials. Log which user made the request so you can track who did what. For user attribution in file history, add the user’s email to revision metadata or file descriptions when your service account makes the API calls. Google Drive will show your app as the editor, but you’ll have detailed user activity logs in your database. This fixes the permission problem completely since all Drive operations go through your authorized service account. You handle user tracking and permissions in your app instead of fighting Google’s OAuth scopes.
yeah, it’s really frustrating! might consider using domain-wide delegation or look at how you handle file sharing in the code. google might need more explicit permission for edit access than you think!
This permissions model screwed me over for months when I built something similar. Google Drive API treats file ownership and user tokens as totally separate layers, even when your service account made the file. I ended up using a hybrid approach - store what users want to change in my database first, then let the service account do the actual work while keeping detailed logs of who changed what. The trick is making user actions trigger service account operations instead of having users hit the API directly. Another thing that helped: create files under the user’s account from the start, not the service account. Then have your service account request access when needed. Flips the whole permission thing but keeps users as owners. The drive.file scope restriction isn’t a bug - it’s intentional security. Work with it instead of asking for broader permissions. Also, do you actually need real-time collaborative editing? Sometimes batched updates through your service account work just as well.
Been there with Drive API headaches. Even though your service account owns the file, Google treats user actions and service account actions as completely separate permission contexts.
When a user tries to edit through your app, Google checks if that specific user authorized your app to access that file. Sharing doesn’t automatically grant API access.
I wrestled with this exact problem until I started handling file operations through automation workflows. Now I intercept user edit requests, process them through an automated pipeline that keeps proper ownership and attribution, then applies changes seamlessly.
You can set up triggers for user actions, route them through your service account for actual Drive operations, but still maintain audit trails showing who made what changes. No need for broader scopes or losing attribution.
I built something similar for our document collaboration system and it works perfectly. Users think they’re editing directly but everything flows through automated processes that handle the permission mess behind the scenes.