Owner: SupportCALL
Website: www.supportcall.com.au
Purpose: Central knowledge base for ICT work, business operations and personal information
Document status: Active
Last reviewed: 8 August 2026

Purpose: Register OAuth access for a public mobile backup application.

Application design: Each user installs the mobile app, selects a cloud-storage provider, signs into their own account and authorises the app to store backups.

Platforms covered:

• Android
• Apple iPhone and iPad

Last verified: 8 August 2026

1. The application owner registers the mobile app with Google, Microsoft and Dropbox.
2. The developer adds the resulting public client IDs to the mobile app.
3. The user installs the app.
4. The user selects Google Drive, OneDrive or Dropbox.
5. The selected provider displays its secure login page.
6. The user signs into their own cloud-storage account.
7. The user approves access to the application's backup folder.
8. The app encrypts the backup on the mobile device.
9. The encrypted backup is uploaded to the user's own cloud account.

The application owner registers each provider only once.

Users must not create their own Google, Microsoft or Dropbox developer applications.

Native mobile applications cannot securely protect client secrets because users can inspect the installed application.

Official references:

• Microsoft OAuth authorisation-code guidance
• Google OAuth client guidance
• Dropbox OAuth guidance

Obtain the following exact information from the mobile-app developer.

Do not invent the Android package name or Apple Bundle ID.

Once an app is published, changing these identifiers normally creates a different application.

Use company-controlled accounts for every registration.

Give at least two trusted company administrators access. Do not make a single person's private email account the only owner.

Even though the application runs on mobile devices, public OAuth applications require a website.

Create these pages before requesting production approval:

• Application homepage
• Privacy policy
• Terms and conditions
• Support or contact page
• Account and cloud-connection deletion instructions

The privacy policy must explain:

• What cloud information the app accesses.
• Why access is required.
• Where OAuth tokens are stored.
• Whether backups are encrypted.
• Whether the developer can access the backups.
• Whether data is shared with another organisation.
• How long information is retained.
• How users disconnect their cloud account.
• How users delete backups and associated information.
• How users contact the application owner.

The website must use HTTPS.

The website and privacy policy must be publicly accessible without requiring a login.

Use one of the following options.

For a conventional encrypted application backup, use:

https://www.googleapis.com/auth/drive.appdata

The Google appDataFolder:

• Is hidden from the normal Google Drive interface.
• Is accessible only by the application that created it.
• Is suitable for application-managed backups and configuration data.
• Cannot be shared through the normal Google Drive sharing system.
• Can be deleted by the user.
• Counts against the user's Google Drive storage quota.

Use drive.file instead when users must see and manually manage the backup files in Google Drive.

Google classifies drive.appdata and drive.file as non-sensitive scopes.

Do not request this broad restricted scope:

https://www.googleapis.com/auth/drive

That scope gives the application broad access to the user's Google Drive.

Official references:

• Google application-data folder
• Google Drive OAuth scopes

Google requires separate development and production projects.

Create:

YOUR APP NAME - Development
YOUR APP NAME - Production

The development project is for:

• Developer testing.
• Debug signing certificates.
• Test users.
• Unreleased builds.

The production project is for:

• Google Play releases.
• Apple App Store releases.
• Production signing certificates.
• Public users.

1. Open Google Cloud Console.
2. Sign in using the company-controlled Google account.
3. Select the project selector at the top.
4. Select New Project.
5. Enter:

YOUR APP NAME - Production

1. Select Create.
2. Wait for the project to be created.
3. Confirm the new production project is selected.

Repeat the process and create:

YOUR APP NAME - Development

Official reference:

• Google production-readiness requirements

Complete these steps inside both Google projects.

1. Open Google API Library.
2. Confirm the correct project is selected.
3. Search for:

Google Drive API

1. Open Google Drive API.
2. Select Enable.
3. Do not enable unrelated APIs.

1. Open Google Auth Platform.
2. Confirm the correct project is selected.
3. Select Get Started.
4. Enter the real public application name.
5. Select the monitored support email.
6. Under Audience, select:

External

1. Enter the developer contact email.
2. Save the configuration.

External is required because any Google user must be able to connect their account.

The current Google interface contains:

• Branding
• Audience
• Clients
• Data Access
• Verification Center

Official reference:

• Google Auth Platform configuration

Open:

Google Auth Platform
→ Branding

Enter:

• Public application name.
• Monitored support email.
• Square application logo.
• Application homepage.
• Privacy-policy URL.
• Terms-and-conditions URL.
• Developer contact email.

Recommended logo:

PNG
Square
120 × 120 pixels or larger
Less than 1 MB

Under Authorised domains, enter only the root domain.

Correct:

example.com

Incorrect:

https://example.com
https://www.example.com/privacy
www.example.com/app

Verify ownership using:

• Google Search Console

Google requires an external production application's homepage and privacy policy to be publicly accessible on a verified domain owned by the application publisher.

Official reference:

• Google OAuth branding requirements

1. Open:

Google Auth Platform
→ Data Access

1. Select Add or Remove Scopes.
2. Search for:

drive.appdata

1. Select:

https://www.googleapis.com/auth/drive.appdata

1. Save the changes.

If backup files must be visible to users in Google Drive, select this scope instead:

https://www.googleapis.com/auth/drive.file

Do not select both unless the application genuinely requires both.

1. Open:

Google Auth Platform
→ Clients

1. Select Create Client.
2. Under Application type, select:

Android

1. Enter a descriptive name:

YOUR APP NAME - Android Production

1. Enter the exact Android package name.
2. Enter the production SHA-1 certificate fingerprint.
3. Select Create.
4. Copy and record the generated Client ID.

For a Google Play release, use the Google Play App signing key certificate.

Open:

Google Play Console
→ Select the application
→ Test and release
→ Setup
→ App integrity
→ App signing
→ App signing key certificate
→ SHA-1 certificate fingerprint

Copy the SHA-1 fingerprint exactly.

Do not accidentally use only the developer's upload-key SHA-1.

Development and production builds may use different signing certificates. Each required signing certificate must have the appropriate OAuth client registration.

Google identifies an Android application using:

• Android package name.
• SHA-1 signing-certificate fingerprint.

Official reference:

• Google Android OAuth client requirements

1. Open:

Google Auth Platform
→ Clients

1. Select Create Client.
2. Under Application type, select:

iOS

1. Enter the exact Apple Bundle ID.
2. Enter the Apple App Store ID when available.
3. Enter the Apple Team ID.
4. Enable Firebase App Check or Apple App Attest protection when supported.
5. Select Create.
6. Record the following:

iOS OAuth client ID
iOS URL scheme
Reversed client ID

The developer adds the reversed client ID to the Apple application's URL schemes.

Official reference:

• Google iOS integration

Complete these steps in the development project.

1. Open:

Google Auth Platform
→ Audience

1. Keep the publishing status as Testing.
2. Find Test users.
3. Add the Google accounts that will test the app.
4. Save.

Test using Google accounts that are not project owners.

Before publishing:

1. Confirm the homepage works.
2. Confirm the privacy policy works.
3. Confirm the terms page works.
4. Confirm the support email is monitored.
5. Confirm the domain is verified.
6. Confirm only the required Drive scope is selected.
7. Confirm production Android signing details are registered.
8. Confirm the correct Apple Bundle ID is registered.
9. Complete backup and restore testing.

Then:

1. Open Verification Center.
2. Complete branding verification.
3. Complete the required basic data-access verification.
4. Open Audience.
5. Change the publishing status to Production.
6. Publish the verified branding when Google reports Ready to publish.

Because drive.appdata is non-sensitive, it avoids the additional sensitive or restricted-scope review. The public application still requires Google's basic production and branding verification.

Use this delegated Microsoft Graph permission:

Files.ReadWrite.AppFolder

This limits the application to its OneDrive application folder:

OneDrive
└── Apps
    └── YOUR APP NAME

The user retains control over their own OneDrive and can delete or modify files inside the folder.

Microsoft currently marks the delegated Files.ReadWrite.AppFolder permission as preview. Test personal and Microsoft 365 accounts before public release.

Official references:

• Microsoft OneDrive application-folder guidance
• Microsoft Graph permission reference

The broader alternative is:

Files.ReadWrite

That permission provides access to all files belonging to the signed-in user.

Do not use Files.ReadWrite without a deliberate security and product decision.

1. Open Microsoft Entra Admin Center.
2. Sign in using a company-controlled Microsoft work account.
3. Open:

Entra ID
→ App registrations
→ New registration

1. Enter the public application name.
2. Under Supported account types, select:

Accounts in any organizational directory
and personal Microsoft accounts

This option supports:

• Personal Microsoft accounts.
• Outlook.com accounts.
• Hotmail accounts.
• Live.com accounts.
• Personal OneDrive accounts.
• Microsoft 365 work accounts.
• Microsoft 365 school accounts.

1. Leave the initial Redirect URI blank.
2. Select Register.
3. Record:

Application (client) ID
Directory (tenant) ID

Official reference:

• Microsoft application-registration instructions

1. Open the new App Registration.
2. Select API permissions.
3. Select Add a permission.
4. Select Microsoft Graph.
5. Select:

Delegated permissions

1. Search for:

Files.ReadWrite.AppFolder

1. Tick the permission.
2. Select Add permissions.

Do not choose the Application permission version.

This application works on behalf of the signed-in user. It therefore requires Delegated permission.

If User.Read was automatically added:

• Keep it if the app displays the Microsoft user's name or profile.
• Remove it if the app does not need Microsoft profile information.

Files.ReadWrite.AppFolder does not normally require administrator consent. A customer's Microsoft 365 administrator can still enforce stricter tenant consent rules.

1. Open the Microsoft App Registration.
2. Select Authentication.
3. Select Add a platform.
4. Select:

Android

1. Enter the exact Android package name.
2. Use Microsoft's displayed keytool command to generate the required signature hash.
3. Enter the generated signature hash.
4. Select Configure.
5. Copy or download the displayed MSAL Configuration.
6. Store it securely with the application's technical documentation.

The Google SHA-1 and Microsoft signature hash are not necessarily entered in the same format. Use the command and format displayed by Microsoft.

Configure the production signing certificate for the Google Play release.

Add a separate Android platform configuration for the development signing certificate when necessary.

Official reference:

• Microsoft mobile redirect configuration

1. Open the Microsoft App Registration.
2. Select Authentication.
3. Select Add a platform.
4. Select:

iOS / macOS

1. Enter the exact Apple Bundle ID.
2. Select Configure.
3. Copy the displayed MSAL configuration.
4. Copy the displayed redirect URI.
5. Give both values to the developer.

1. Remain under Authentication.
2. Find Advanced settings.
3. Set:

Allow public client flows: Yes

1. Select Save.

Do not create:

• Client secret.
• Client certificate.
• Federated credential.

These credentials are for confidential server applications. They do not belong inside a public mobile application.

The developer should use Microsoft's MSAL library.

MSAL supports:

• Authorization Code with PKCE.
• Secure system-browser authentication.
• Access-token management.
• Refresh-token management.
• Microsoft account selection.
• Redirect handling.

Open:

App Registration
→ Branding & properties

Enter:

• Application logo.
• Homepage URL.
• Privacy-statement URL.
• Terms-and-conditions URL.
• Support contact.
• Publisher domain.

Verify the publisher domain.

A public commercial app serving Microsoft 365 organisations should complete Publisher Verification.

Without Publisher Verification:

• Users may see an unverified-publisher warning.
• Some organisations may block user consent.
• Microsoft 365 administrators may require manual approval.

Publisher Verification normally requires enrolment in the Microsoft AI Cloud Partner Program.

Open:

App Registration
→ Branding & properties
→ Add Partner ID

Enter the organisation's Microsoft Partner identifier and complete verification.

Official references:

• Microsoft Publisher Verification overview
• Microsoft Publisher Verification procedure

Use:

Scoped access
App folder

This restricts the application to:

Dropbox
└── Apps
    └── YOUR APP NAME

Do not select Full Dropbox for an application that only stores and restores its own backups.

The Dropbox access type cannot be changed later.

Changing from App folder to Full Dropbox requires creation of a new Dropbox application.

Official reference:

• Dropbox OAuth guidance

1. Open Dropbox App Console.
2. Sign in using the company-controlled Dropbox account.
3. Select Create app.
4. Choose:

Scoped access

1. Choose:

App folder

1. Enter a unique public application name.
2. Select Create app.
3. Record:

Dropbox App key

The App key is the public client identifier used by the mobile application.

Do not put the Dropbox App secret inside the mobile application.

Open the Permissions tab.

Select only:

files.metadata.read
files.content.read
files.content.write

These scopes permit the application to:

• List its backup files.
• Read file metadata.
• Upload backup files.
• Download backup files.
• Replace backup files.
• Delete obsolete backup files.

Add this permission only when the app displays the connected Dropbox account's name:

account_info.read

Do not select:

• Sharing permissions.
• Team-management permissions.
• Team file permissions.
• Contact permissions.
• Full Dropbox access.

Select Submit or Save.

Open the Settings tab.

Set:

Allow implicit grant: Disabled

The developer must use:

OAuth 2.0 Authorization Code
PKCE S256
Short-lived access tokens
Refresh token
Offline access

For long-term background backups, the Dropbox OAuth request must include:

token_access_type=offline

The official Dropbox mobile SDK handles the callback using a URL scheme based on the App key:

db-DROPBOX_APP_KEY

This value is configured inside:

• The Android application manifest.
• The Apple application's URL configuration.

Do not invent a separate redirect URI.

Add a redirect URI to the Dropbox console only when the SDK or implementation provides an exact URI that must be registered.

Official reference:

• Dropbox PKCE and refresh-token instructions

Open the Branding tab.

Enter:

• Public application name.
• Publisher or company name.
• Accurate app description.
• Application website.
• Privacy-policy address where requested.
• Application icons.

Recommended access description:

The application accesses only its own Dropbox application folder
to upload, list, download and delete encrypted backup files.

Do not claim that Dropbox itself encrypts the backup end to end.

The mobile application must encrypt the backup before uploading it.

Initially, only the Dropbox account that owns the application can connect.

1. Open Settings.
2. Find Development users.
3. Select Enable additional users.
4. Test with several independent Dropbox accounts.

A generated access token from the Dropbox console is for owner testing only.

Never include a generated owner access token in:

• Mobile application code.
• Application configuration files.
• Source-control repositories.
• Documentation.
• Screenshots.
• Support messages.
• Crash reports.

Complete this before releasing the mobile application.

1. Open Settings.
2. Find Status.
3. Select Apply for Production.
4. Complete the production-readiness form.
5. Supply the application website.
6. Supply the privacy policy.
7. Supply an accurate app description.
8. Explain why the selected permissions are required.
9. Explain that access is restricted to the Dropbox App Folder.
10. Submit the application for review.
11. Correct any issues Dropbox reports.
12. Resubmit when necessary.

Dropbox development applications support only a limited number of users.

Dropbox states that an application reaching 50 linked users must obtain production approval to continue linking additional users.

Apply for production before the public mobile-app release.

Official references:

• Dropbox production guidance
• Dropbox App Console guide

The following are public identifiers and may be included in the mobile application:

• Google Android client ID.
• Google Apple client ID.
• Microsoft Application client ID.
• Dropbox App key.
• Android package name.
• Apple Bundle ID.
• Registered callback schemes.

The following must remain confidential:

• User access tokens.
• User refresh tokens.
• Provider app secrets.
• Owner-generated testing tokens.
• User passwords.
• Backup-encryption keys.
• Recovery keys.
• Private signing keys.

The developer must implement:

• Authorization Code with PKCE.
• PKCE method S256.
• A new random code verifier for every authorisation attempt.
• A new random state value for every authorisation attempt.
• State validation after the provider redirects back.
• Provider SDK or system-browser login.
• Secure token storage.
• Token-expiry handling.
• Refresh-token handling.
• User cancellation handling.
• Provider-error handling.
• Account disconnection.
• Provider-token revocation.
• Removal of local tokens after disconnection.

The app must not:

• Ask users for their Google password.
• Ask users for their Microsoft password.
• Ask users for their Dropbox password.
• Display provider login pages in an untrusted WebView.
• store tokens in normal application preferences.
• Store tokens in plain-text files.
• Include provider secrets in compiled code.
• Log OAuth codes or tokens.
• Send OAuth tokens to analytics services.

OAuth authorises cloud access. OAuth does not encrypt the backup contents.

Before uploading, the mobile app must:

1. Create the backup locally.
2. Encrypt the complete backup.
3. Create a cryptographic checksum.
4. Upload only the encrypted backup.
5. Upload a versioned manifest.
6. Verify the uploaded size and checksum.
7. Retain the required number of backup versions.
8. Remove obsolete versions according to the retention policy.
9. Never upload the encryption key inside the same backup.

Recommended backup structure:

/backups/
    manifest.json.enc
    backup-2026-08-08T090000Z.bin.enc
    backup-2026-08-01T090000Z.bin.enc
    backup-2026-07-25T090000Z.bin.enc

The restore process must:

1. Download the selected encrypted backup.
2. Verify the checksum.
3. Decrypt locally on the device.
4. Validate the backup format.
5. Prevent a corrupt backup from overwriting working local data.
6. Create a local safety copy before restoring.

The app must provide:

• Connect Google Drive
• Connect Microsoft OneDrive
• Connect Dropbox
• Connected account display
• Last successful backup date and time
• Last backup result
• Backup-now button
• Restore-backup button
• Available backup versions
• Cloud-storage-space warning
• Disconnect-cloud-storage button
• Delete-cloud-backups option
• Export-recovery-key option where applicable
• Clear explanation that deleting the recovery key may make encrypted backups permanently unreadable

Complete every test before release.

• Connect a Google account that is not a project owner.
• Reject the Google consent request.
• Confirm the app returns safely.
• Approve the Google consent request.
• Upload an encrypted backup.
• Restart the mobile app.
• Confirm the connection remains available.
• Restore the backup.
• Revoke access from the Google Account.
• Confirm the app detects the revoked access.
• Confirm the app requests authorisation again.
• Test the final Android production-signed build.
• Test the final Apple TestFlight build.

• Connect a personal Outlook or Hotmail account.
• Connect a personal OneDrive account.
• Connect a Microsoft 365 work account.
• Reject Microsoft consent.
• Approve Microsoft consent.
• Upload and restore a backup.
• Test token expiry.
• Test silent token renewal.
• Test an organisation that restricts user consent.
• Confirm admin-approval errors are clearly displayed.
• Disconnect the Microsoft account.
• Confirm local tokens are removed.

• Connect a Dropbox account that does not own the developer app.
• Reject Dropbox authorisation.
• Approve Dropbox authorisation.
• Confirm the app can access only its App Folder.
• Upload an encrypted backup.
• Restore the backup.
• Test refresh-token operation.
• Revoke Dropbox access.
• Confirm the app requests authorisation again.
• Disconnect the account.
• Confirm local tokens are removed.

Test:

• No internet connection.
• Very slow internet connection.
• Interrupted upload.
• Interrupted download.
• Expired access token.
• Revoked refresh token.
• Full cloud-storage quota.
• User deletes the app folder.
• User deletes a backup file.
• User reinstalls the mobile app.
• User changes cloud accounts.
• User connects the wrong account.
• Duplicate backup names.
• Corrupt backup file.
• Incorrect recovery key.
• Mobile device runs out of storage.
• App closes during backup.
• Device restarts during backup.
• Background task is stopped by Android or iOS.
• Cloud provider returns an API rate-limit error.
• Cloud provider is temporarily unavailable.

• Google production project created.
• Google Drive API enabled.
• Google audience set to External.
• Google branding completed.
• Google domain verified.
• Google privacy policy accepted.
• Google non-sensitive Drive scope selected.
• Google Android production client created.
• Google Apple client created.
• Google verification completed.
• Google project moved to Production.
• Microsoft multitenant app registered.
• Personal Microsoft accounts enabled.
• Microsoft delegated AppFolder permission selected.
• Microsoft Android configuration completed.
• Microsoft Apple configuration completed.
• Microsoft public-client flow enabled.
• Microsoft publisher domain verified.
• Microsoft Publisher Verification completed where required.
• Dropbox Scoped Access selected.
• Dropbox App Folder selected.
• Dropbox minimum permissions selected.
• Dropbox implicit grant disabled.
• Dropbox branding completed.
• Dropbox production approval received.
• No client secrets are embedded in the mobile app.
• PKCE S256 is enabled for every provider.
• Tokens are stored in Android Keystore or Apple Keychain.
• Backups are encrypted before upload.
• Backup checksums are verified.
• Cloud disconnection works.
• Provider revocation works.
• Privacy policy matches actual application behaviour.
• Tokens and encryption keys are excluded from logs.
• Production Android signing has been tested.
• Production Apple build has been tested.