Detecting when application loses Google Drive authorization access

[emmat83]

I’m working on an application that saves user data to Google Drive using the application folder. Everything works fine for uploading and downloading files, but I have an issue with checking permissions.

Users can revoke app access from their Google Drive settings, and I need to detect this on the client side. I’m using DriveScopes.DRIVE_APPDATA which corresponds to https://www.googleapis.com/auth/drive.appdata.

When the app tries to use Drive APIs after being disconnected, it throws a UserRecoverableAuthIOException:

try {
    DriveResourceManager driveManager = new DriveResourceManager();
    FileMetadata fileData = driveManager.uploadUserData(userData);
} catch (UserRecoverableAuthIOException exception) {
    // App crashes here when disconnected
    Log.e("DriveError", "Authentication failed", exception);
}

I’ve tried two approaches to check permissions before making API calls:

Method 1: Checking GoogleSignInAccount scopes

GoogleSignInAccount userAccount = GoogleSignIn.getLastSignedInAccount(context);
Set<Scope> availableScopes = userAccount.getGrantedScopes();
// This still shows drive.appdata scope even when disconnected

Method 2: Using GoogleSignIn.hasPermissions()

boolean hasAccess = GoogleSignIn.hasPermissions(userAccount, 
    new Scope(DriveScopes.DRIVE_APPDATA));
// This returns true even when app is disconnected

Both methods show that permissions are still granted even after the user disconnects the app. How can I properly detect when my app has been revoked from Google Drive?

[Isaac_Cosmos]

This happens because Google caches auth tokens locally even after you revoke them. The validation only kicks in server-side when you actually make API calls. I’ve hit this same issue before - the best fix is adding a quick permission check with a minimal API call. Just request to list files in your app folder with zero page size. It triggers auth validation without moving any real data. Wrap it in a method that catches UserRecoverableAuthIOException and handles it cleanly. Now you can check access before running your main stuff. There’s barely any overhead since you’re not pulling actual file content. You could also run a background check that updates a local flag showing current auth status - keeps your app from crashing unexpectedly.

[mythicMuse]

The Problem:

You’re experiencing authentication issues with your application, specifically, it crashes when a user revokes your app’s access to their Google Drive. The application uses the Google Drive API, and existing attempts to check permissions using GoogleSignInAccount scopes and GoogleSignIn.hasPermissions() fail to detect the revoked access. The application crashes with a UserRecoverableAuthIOException.

Understanding the “Why” (The Root Cause):

The core issue is that you are trying to handle authentication and authorization entirely within your application’s client-side code. Google’s authentication mechanism involves caching tokens locally, meaning the revocation of access isn’t immediately reflected in client-side permission checks. Attempting to verify access using client-side methods will yield incorrect results because the cached tokens might still be valid locally even if the user has revoked the application’s access in their Google Drive settings. The crash occurs when the application attempts to use an invalidated token on the Google Drive server. The solution involves shifting the authentication and authorization logic outside the client and into a more robust system.

Step-by-Step Guide:

Step 1: Implement an External Authentication Workflow:

Instead of directly using Google Drive APIs within your application, create an external workflow (using a service like Latenode or a custom backend service) to manage all Google Drive interactions. This external system will act as an intermediary between your application and Google Drive.

1. Design API Endpoints: Create API endpoints (e.g., /upload, /download, /check_permissions) in your external workflow system. Your application will communicate with these endpoints instead of directly calling Google Drive APIs.
2. Handle Authentication: The external system should manage authentication and handle authorization with Google Drive. It should use appropriate refresh token management to keep the connection active, gracefully handling authentication failures and refresh token expirations.
3. Proxy Drive Operations: The endpoints will perform the necessary Google Drive operations (upload, download, etc.). If authentication fails, the external system can properly handle the error (e.g., return an error code or trigger a re-authentication flow).

Step 2: Modify Your Application’s Logic:

Modify your application to interact with the new API endpoints in your external workflow rather than calling the Google Drive API directly. For example, the code to upload user data would now look like this (assuming an /upload endpoint):

try {
    // Call external service API instead of directly accessing Drive APIs
    ApiService apiService = new ApiService();
    FileMetadata fileData = apiService.uploadFile(userData); 
} catch (IOException exception) {
    // Handle network or API errors appropriately
    Log.e("APIError", "API request failed", exception);
}

Step 3: Implement Error Handling and Retries:

Both your external workflow and your application should include robust error handling. The external workflow should manage re-authentication attempts. The application should gracefully handle errors returned by the external API, providing informative error messages to the user.

Common Pitfalls & What to Check Next:

• External Service Reliability: Ensure your chosen external workflow system (e.g., Latenode) is reliable and can handle potential failures and scaling issues.
• API Security: Securely protect your API endpoints. Use appropriate authentication and authorization mechanisms to prevent unauthorized access.
• Rate Limiting: Implement rate limiting and exponential backoff to avoid exceeding Google Drive API usage limits.

Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!

[Zack_45Gaming]

i had similar issues. the google api has a bit of a delay in reflecting permissions changes. just proceed with a simple api call and check for errors. if it crashes, then that means access is gone. hope this helps!