Firedeck Security & OAuth Architecture
1. Overview
Firedeck is a client-side iOS app for working with Firebase and Google Cloud resources the signed-in user already owns or has access to. It is a thin client over official Google and Firebase REST APIs — not a cloud intermediary, token broker, or backend management service. Every authenticated request is sent from the user’s device and acts strictly as the signed-in Google user.
2. No backend infrastructure
- Firedeck has no backend API, Cloud Function, or Cloud Run service.
- Firedeck does not proxy Firebase or Google Cloud requests through any developer-controlled server.
- All authenticated traffic flows directly from the iOS app to first-party Google API hosts, such as:
firestore.googleapis.comfirebase.googleapis.comfirebaseremoteconfig.googleapis.comstorage.googleapis.comidentitytoolkit.googleapis.comfcm.googleapis.comcloudfunctions.googleapis.comfirebaseappdistribution.googleapis.comfirebasehosting.googleapis.comfirebaserules.googleapis.comfirebaseappcheck.googleapis.comfirebaseextensions.googleapis.comcloudresourcemanager.googleapis.comiam.googleapis.comlogging.googleapis.comcloudbilling.googleapis.comfirebasedatabase.googleapis.com<user-owned RTDB>.firebaseio.com<user-owned RTDB>.firebasedatabase.app
3. No token vault or server-side token storage
- Firedeck does not store Google OAuth access tokens or refresh tokens on any Firedeck-controlled server.
- Firedeck does not operate a token vault.
- Tokens are managed by the official Google Sign-In iOS SDK, which uses iOS security mechanisms such as the Keychain to store its own session state.
- Firedeck reads the current access token from the signed-in Google user only at the moment it attaches it to an outgoing Google/Firebase API request. Firedeck does not persist, mirror, export, or transmit OAuth tokens.
4. No Firebase Admin SDK, service accounts, or impersonation
- Firedeck does not bundle or use the Firebase Admin SDK.
- Firedeck does not use service account keys and does not sign JWTs to impersonate service accounts.
- Firedeck does not impersonate users.
- All operations are performed with the OAuth permissions of the currently signed-in Google account — nothing more.
5. Direct OAuth Bearer requests
- Authenticated API calls attach
Authorization: Bearer <Google OAuth access token>at the request layer, and only to Google/Firebase API hosts. - Firedeck does not use cookies, custom sessions, or server-generated credentials for Firebase access.
- If the user signs out, the locally signed-in state is cleared and subsequent authenticated requests fail until the user signs in again.
6. User-owned and user-accessible projects only
- Project lists are returned by Google/Firebase APIs based on the user’s OAuth token.
- Firedeck can only display projects and resources the user already has access to through Google IAM and Firebase permissions.
- Firedeck cannot independently access arbitrary Firebase projects, and it has no shared credentials or hardcoded project list.
7. Scope usage and least privilege
Firedeck’s Google Sign-In configuration requests one scope per Firebase capability so Google’s consent screen renders a granular checkbox UI. The user can decline any individual scope; declining a scope simply makes the corresponding feature unavailable. Scopes are requested only for capabilities the app actually exposes:
| Scope | Purpose | User-visible feature |
|---|---|---|
openid | Sign-in identity baseline. | Google Sign-In to the app. |
email | Display the signed-in account address. | Account header, account switcher, support context. |
profile | Display the account profile and avatar. | Account header / profile chip. |
https://www.googleapis.com/auth/cloudplatformprojects.readonly | List the user's Google Cloud projects in the project picker. | Project picker and project list. |
https://www.googleapis.com/auth/firebase.readonly | Read Firebase Management resources the user already has access to (projects, apps, configs, Hosting metadata). | Project detail, app list, Hosting overview, App Distribution overview, Remote Config read. |
https://www.googleapis.com/auth/firebase | Write Firebase Management resources for user-initiated edits (Remote Config, App Distribution, Hosting, Security Rules, App Check, Extensions, RTDB admin, Auth users). | Explicit, user-initiated writes inside Firebase management surfaces. |
https://www.googleapis.com/auth/firebase.messaging | Send FCM v1 messages composed by the user. | Cloud Messaging composer. |
https://www.googleapis.com/auth/datastore | Firestore data-plane access (browse, create, update, delete documents). | Firestore browser and document editor. |
https://www.googleapis.com/auth/devstorage.read_only | List and download Cloud Storage buckets and objects. | Cloud Storage browser and object preview. |
https://www.googleapis.com/auth/cloud-platform | Requested incrementally only when the user invokes a feature that requires broader Google Cloud authorization. Never requested at initial sign-in. | Triggered the first time the user opens Functions, IAM, Logging, or billing surfaces, uploads to Cloud Storage, edits a Firestore document, or saves a Remote Config parameter. |
The broader cloud-platform scope is not requested at initial sign-in. It is requested incrementally via a Google Sign-In addScopesprompt the first time the user invokes a feature that requires it — for example, opening Cloud Functions, IAM, Cloud Logging, or billing surfaces; uploading to Cloud Storage; editing a Firestore document; or saving a Remote Config parameter. If the user declines the incremental prompt, the action fails closed and the user can be re-prompted later. Firedeck never silently issues unauthorized requests.
8. Write operations are explicit
- Firestore writes happen only when the user creates, edits, or deletes a document in the in-app editor.
- Cloud Storage uploads happen only when the user picks a file/object and confirms the upload.
- Remote Config updates happen only when the user edits a parameter and saves it.
- Firedeck does not perform background bulk modifications or sync jobs against user projects.
- Write use cases ensure the required
cloud-platformscope before issuing the request. If the scope is not yet granted, a Google Sign-InaddScopesprompt is shown contextually next to the user’s action; if the user declines, the action surfaces an error instead of issuing an unauthorized request. - A small set of higher-impact admin actions (e.g. disabling Auth users, setting custom claims, sending Cloud Messaging campaigns, promoting Hosting channels, modifying App Distribution testers) is gated behind a feature flag and is not exposed in the current release.
9. Data handling
- Firedeck does not sell Google user data.
- Firedeck does not use Firebase project contents for advertising.
- Firedeck does not centrally aggregate, copy, or warehouse Firebase project data on developer-controlled servers.
- Firebase and Google Cloud data fetched by the app is rendered on-device and used only to provide the visible Firebase productivity features the user interacts with.
- Firedeck uses third-party services for diagnostics, crash reporting, and subscription management (Firebase Analytics, Firebase Crashlytics, and RevenueCat). These services receive standard mobile telemetry (device model, OS version, app version, crash reports, anonymous usage events, purchase/subscription status). They do not receive the contents of the Firebase projects the user inspects through the app.
10. Host validation and API destination safety
- The request layer attaches the user’s OAuth bearer token only when the request is targeted at a Google/Firebase API host (
*.googleapis.com,*.firebaseio.com,*.firebasedatabase.app). - For Realtime Database, user-entered database URLs are validated in release builds to require HTTPS and a Firebase database domain (
.firebaseio.comor.firebasedatabase.app) before the OAuth token is attached, to prevent the token from being sent to an arbitrary host.
11. User control
- Sign-in is initiated by the user, never silently.
- The user can sign out from the app at any time.
- The user can revoke Firedeck’s access at any time from Google Account → Third-party apps with account access.
- Effective access at all times is governed by the user’s Google IAM and Firebase permissions on the selected project.
12. Contact
- Developer: Adam Gelatka
- Support email: gelatka.adam@gmail.com
- Privacy policy
- Terms of use
- Firedeck app page