Airflow login with Google Workspace: FAB setup guide

How Airflow 3 signs users in with Google Workspace

If your team runs self-hosted Airflow 3 and wants Workspace accounts to replace local passwords, Google sign-in is configured through the FAB auth manager's google OAuth provider in webserver_config.py. The work has three parts: restricting sign-in to your Google domain, assigning roles to each user, and deciding what role a brand-new user receives on first login. Airflow 3 ships with the Simple auth manager as its default, and it allows only one auth manager at a time, so you must select FAB explicitly through the auth_manager option in your Airflow configuration before any of the OAuth settings take effect. Confirm the FAB provider version you install against the provider documentation, since the auth manager comes from the FAB provider package rather than from core Airflow.

The design decision that shapes everything else is that Google does not send group memberships in the standard sign-in. A role mapping based on AUTH_ROLES_MAPPING depends on the identity provider returning group or role claims, so with plain Google sign-in you cannot map Google groups to Airflow roles without an additional source of group data. Decide early how roles will be assigned: a short, fixed list of named users, a default role for every verified Workspace account, or a separate directory or identity provider that holds group membership and supplies it to Airflow. Each option changes who can reach admin functions, so agree the model with your security team before the first login test. Ask your Google Workspace administrator which domain, organizational unit and account types will be allowed to sign in, because those answers define the restriction you configure.

New-user handling is the control most likely to surprise you. AUTH_USER_REGISTRATION lets an unknown user be created at first login, and the role that user receives is set by the default registration role. If your Workspace domain contains contractors, shared service accounts or former employees who still have active accounts, a broad default role gives them access to DAGs they should not see. Test the full path with a non-admin account from your domain and with an account from outside it, then confirm the role and visibility each one gets. Keep a local break-glass admin available until the Google path is verified, and document who can change AUTH_ROLES_MAPPING and AUTH_ROLES_SYNC_AT_LOGIN settings in your change process. The FAB webserver authentication documentation lists the exact settings your provider version supports.

What you need before configuring Google sign-in

Google sign-in for Airflow depends on the platform version, the database, the FAB provider, a Google Cloud OAuth client and a public hostname. Confirm these pieces first, because a gap in any one of them usually shows up as a failed login after the configuration change rather than as a clear error.

Airflow 3 and its prerequisites

Google sign-in is configured on an Airflow 3 deployment, currently at patch release 3.3.2. Confirm the runtime against the prerequisites: Python 3.10 to 3.14, PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or an Innovation release, and Kubernetes 1.30 to 1.35 if you run on Kubernetes. If you are still on Airflow 2, complete the upgrade first, since login changes made on the old webserver will not carry over to the API server.

Production metadata database

The metadata database stores users, roles and sessions, so the login setup depends on it. SQLite must not be used in production because it can lead to data loss, and MariaDB is not a supported metadata database. Confirm that PostgreSQL or MySQL is in place, backed up and reachable from every API server and scheduler before you change anything about authentication.

FAB provider for your Airflow version

Airflow 3 allows one auth manager at a time, and the FAB auth manager comes from the FAB provider package rather than from core Airflow. Install the FAB provider version that matches your Airflow release, then set the auth manager in the configuration. Record the exact provider version so that a later upgrade does not silently change how OAuth login behaves.

Google Cloud OAuth client and redirect URL

Create an OAuth client in Google Cloud and register the exact redirect URL that the Google provider will call on your public API server hostname. A mismatch between the registered URL and the one Airflow sends is the most common cause of a failed sign-in. Store the client ID and secret in your secrets manager, not in plain configuration files.

Workspace admin approval

Depending on how your Google Workspace is configured, an administrator may need to approve the OAuth app or restrict it to internal users before employees can sign in. Ask the Workspace admin who will approve the app, which Google Cloud project owns the client, and whether the consent screen is set to internal. Without this step, sign-in fails for most users even when the configuration is correct.

Stable public HTTPS hostname and break-glass admin

Google redirects users back to a fixed HTTPS address on the API server, so that hostname must be stable, public and covered by a valid certificate. Before changing authentication, create a local break-glass admin account and confirm you can sign in with it. If the OAuth configuration locks out every user, this account is the way back in.

Configuration sequence for the google provider

This sequence moves Airflow 3 from its default login to Google sign-in through the FAB auth manager, limited to one Workspace domain. It ends with a default role for first-time users, role assignment that matches your chosen strategy, and tests that confirm members can sign in, outsiders are refused and a break-glass account still works.

Create the Google Cloud OAuth client
A Google Cloud project owner creates an OAuth client for a web application in the Google Cloud console and records the client ID and client secret. Add the redirect URL that the FAB google provider expects for your Airflow API server address, copying the scheme, host and path from the FAB webserver authentication documentation, because Google rejects any mismatch. If every user is in your Workspace organization, confirm whether the consent screen can be set to internal in the current console. Store the secret in your secrets manager and keep it out of shared documents. Done when the client ID and secret are saved and the redirect URL in Google matches the documented path exactly.
Set the FAB auth manager
In airflow.cfg or the matching environment variable, set the auth_manager option to the FAB auth manager class from the FAB provider. Confirm that the provider package is installed in the same image or virtual environment as the API server, because Airflow 3 runs only one auth manager at a time and the default Simple auth manager must be replaced by FAB. Done when the API server starts cleanly under the same configuration you plan to deploy to staging.
Add the google provider to webserver_config.py
Edit webserver_config.py, set AUTH_TYPE to the OAuth mode, and add a google entry to OAUTH_PROVIDERS. Load the client ID and secret from environment variables instead of writing them as literal text in the file. Use the provider name and keys listed for Google in the FAB webserver authentication documentation, since small naming differences cause silent login failures. Done when the file imports in a Python shell without errors and the client secret is read from the environment.
Restrict sign-in to your Workspace domain
Add a check that runs after Google returns the user's profile and rejects any account whose email address does not end in your Workspace domain. Google's hd claim can support this check, but treat it as a supporting signal and validate the email domain directly. Implement the check as a custom security manager hook in webserver_config.py, and confirm the hook name against your FAB provider version. Done when a personal Gmail account is refused with an access message and the rejection appears in the logs.
Set registration and the default role
Set AUTH_USER_REGISTRATION to True so that members who have never signed in get an account on their first login. Set AUTH_USER_REGISTRATION_ROLE to the least-privileged role you intend for new users, such as Viewer, and confirm the exact option and role names for your FAB version. Done when a new member's first login creates an account holding only that role and an administrator can see the account in the user list.
Configure role mapping and role sync
Choose the role strategy before you write any mapping. Google does not send groups in the sign-in token by default, so decide where role membership will come from, such as a short list of approved addresses enforced in your custom security manager or Workspace group lookups that your team builds against the Google Admin SDK. Set AUTH_ROLES_MAPPING to connect each source value to an Airflow role, and set AUTH_ROLES_SYNC_AT_LOGIN to True so roles are checked on every login. Done when a test user's role changes after you update the source list and that user signs in again.
Restart the API server
Restart the Airflow API server so it loads the new webserver_config.py and auth manager settings. If the DAG processor or scheduler reads the same configuration, restart those components as well. In your deployment tool, confirm that every API server replica is running the new configuration, since a replica left on the old settings will accept logins that the others refuse. Done when all replicas report the new configuration and the login page sends users to Google.
Test with member, outsider and break-glass accounts
Run three sign-in tests. A Workspace member should reach Airflow with the role your mapping assigns. An outside-domain account should be refused at the domain check. A break-glass administrator account should still sign in if Google is unavailable. Confirm with your FAB version how a local account stays available alongside OAuth before go-live. Done when all three results match the expected outcome and the test evidence is saved with the change record.

Choosing a role strategy when Google sends no groups

This is the simplest option. Every person who signs in with an allowed Google account receives the same default role, and an administrator promotes individuals by hand inside Airflow. It suits a small team, a proof of concept or a deployment with few operators who all know each other. The default role for new users is set through the registration settings in webserver_config.py, so confirm that value before go-live, because it decides what a newly created account can see.

Low build effort: no mapping logic is needed, so the configuration is limited to domain restriction and the default role.
Manual promotion becomes the control: every elevated role is a manual change, so each one needs a ticket or approval record kept outside Airflow.
Weak audit evidence: role history lives in the Airflow metadata database unless someone exports it, and a manual change is hard to tie back to a request.
Leavers depend on a separate step: a disabled Google account cannot sign in, but the Airflow user record and its roles remain until someone removes or deactivates them.
Scales poorly: each new operator, team change or periodic role review adds manual work for the administrator.

Before choosing this option, confirm how your FAB provider version treats an existing user whose Google account has been disabled, and name who approves each promotion.

In this option, you maintain a list of email addresses and their Airflow roles in a store you control, such as a version-controlled file, a database table or a managed configuration repository. At login, Airflow matches the signed-in address against the list and assigns the matching role. This depends on the login response including the email address, which you should confirm with a test login. The list becomes the source of truth for elevated access, so its ownership and review process matter as much as the code.

Single source you control: the list is versioned, so changes have a clear owner and a history you can show an auditor.
Maintenance grows with headcount: every joiner, mover and leaver must be reflected in the list, and someone must own that work.
Stronger audit trail: changes can go through review and approval, and the commit or ticket history shows who granted what and when.
Leaver handling depends on the list: if AUTH_ROLES_SYNC_AT_LOGIN re-checks roles on each login, removing an address changes access at the next sign-in, which you should verify in staging.
Drift risk: the list can disagree with HR and Google records unless a scheduled review compares them.

Ask whether your organization can name an owner for the list and a review cadence, because the control holds only when both exist.

In this option, Airflow looks up the user's Google Workspace group membership through a separate directory query after sign-in, then maps those groups to Airflow roles with AUTH_ROLES_MAPPING. Because the sign-in response does not carry groups in this scenario, the directory lookup becomes an additional component. It needs its own identity, read permissions, secret storage and error handling. The exact directory API, scopes and how the lookup connects to FAB must be confirmed against the FAB and Google documentation before design begins.

Extra data source and credentials: the lookup needs an identity with directory read permissions, which the security team must approve and rotate.
Custom code to maintain: the lookup is not part of the standard sign-in flow described here, so your team owns its upgrades and failure handling.
Strong alignment with existing process: group membership is maintained by the identity team in Google, so access follows the organization's directory process.
Leaver handling follows directory state: removing someone from a group or disabling the account should change access at next login, subject to how role sync runs, so test this path.
Failure behavior needs a decision: if the lookup fails or times out, decide whether login is denied or falls back to a default role, and document that choice.

Confirm which directory API and scopes apply, and whether the lookup can run at every login, before committing to this design.

Whichever option you choose, a few facts determine whether the design works in your environment. Confirm them with a test deployment and record the answers in the design document, so the role strategy can be explained to auditors later. Most of these checks take place in the identity provider and the Airflow configuration, not in the DAG code, so they involve both the platform and identity teams.

Auth manager version: confirm the FAB provider version and the webserver_config.py keys it supports for your Airflow 3 release.
Claims received: run a test login and record which claims arrive, including the email address and any domain claim Google returns for Workspace accounts.
Domain restriction: test that an account outside your domain is rejected before anyone outside the organization can reach the login page.
Break-glass admin: keep one administrative path that works if Google or the directory lookup is unavailable.
Ownership: name who approves role changes, who reviews the mapping on a schedule and who responds when a sign-in fails.

Review the FAB webserver authentication documentation against your version before writing the design.

Attributes and roles mapped from Google to Airflow

This table shows which Google account attributes become Airflow identity fields, which setting assigns the first role, and where team roles come from. Read it as a checklist: Google Workspace sign-in usually supplies identity and domain, but role assignment depends on values you confirm against your FAB provider version before go-live.

Attribute or setting	What it maps to in Airflow	What to confirm
Google account email	Airflow username and email for the user record	Confirm which claim your FAB version uses as the username and that it matches the email address users sign in with
Hosted domain claim (hd)	Used to restrict sign-in to your Google Workspace domain	Confirm the domain check is enforced in the OAuth provider configuration, not only in the UI
AUTH_USER_REGISTRATION	Creates a user record on first sign-in when the user is unknown	Confirm it is enabled only if you want first-login accounts created automatically
Default role for new users	The role assigned at first login, before any team mapping applies	Set this to the least-privileged role, such as Viewer or Public, and confirm the value in your version
Group or role source for AUTH_ROLES_MAPPING	Maps identity provider groups or roles to Airflow roles	Google sign-in does not always send group membership, so confirm whether your setup receives groups or needs a separate directory lookup
AUTH_ROLES_SYNC_AT_LOGIN	Re-checks mapped roles on every login so removed group membership takes effect	Confirm the setting is on, since otherwise roles may persist after a team change
Admin role	Full administrative access to Airflow, including users and connections	Restrict to a small named group and keep a documented break-glass admin
Op and User roles	Operational control of DAG runs and standard DAG access for working teams	Confirm the permissions each role carries in your Airflow 3 and FAB version
Viewer and Public roles	Read-only access for stakeholders, and the most limited role for unmapped users	Confirm what Public can see before using it as a default role

Restricting access to your Google Workspace domain

A Google OAuth client on its own does not limit Airflow to your company. Any Google account can complete a sign-in against that client, including personal Gmail addresses, so Airflow would accept them unless something stops the login. Two controls close the gap, and they do different jobs. First, set the OAuth consent screen in Google Cloud to Internal, which allows only accounts in your Google Workspace organization to authorize the app. Second, check the hosted domain claim, hd, in the ID token Google returns, and reject the login when it does not match your domain. Google enforces the consent screen, so it is the primary control. The hd check is your own safeguard in the OAuth callback configured through webserver_config.py, and it should stay in place even after the consent screen is set. Confirm that the FAB Google provider version you deploy passes the claim through to your code before you rely on it.

Test the restriction before you trust any role logic. Use two accounts that must fail: one from a different Workspace domain, such as a partner or contractor tenant, and one personal Gmail account. Both must be refused at the login step, so the request never reaches role mapping. Afterward, check the Airflow user list and the metadata database for new rows, because AUTH_USER_REGISTRATION can create a user at first login and a refused login must leave no record behind. Review the webserver logs to confirm that the rejection came from the domain check or the consent screen, not from a later error. Then run the same test with an account from your own domain, which should succeed and receive only the role you intended. Repeat these checks after any change to the OAuth client, the consent screen or the callback code, since a single edit can reopen the gap.

Hardening Google sign-in for Airflow

Google sign-in decides who can reach Airflow, but it does not decide what they can do once inside. The cards below cover the controls that sit around the OAuth login: where the client secret lives, how the API server is encrypted, how long sessions last, how a break-glass admin is kept, and how role changes are reviewed and logged. Work through them together before go-live, since each one closes a gap the others leave open.

Keep the client secret out of config

The Google OAuth client secret is set in webserver_config.py for the FAB google provider, and that file is often committed to version control or copied between environments. Move the secret into a secrets backend or an environment variable injected at runtime, and confirm the file only references it. Check that the secret does not appear in logs, Helm values, container images or CI output, and plan a rotation procedure that does not require a code change. Ask Google Cloud administrators who can read and rotate the OAuth client.

Terminate TLS on the API server

The Airflow 3 API server serves the login flow and the redirect back from Google, so the hostname registered with Google must use HTTPS end to end or at a trusted ingress. Confirm the redirect URI matches the public hostname exactly, and that cookies are marked secure so session tokens are not sent over plain HTTP. Restrict internal traffic between the API server, scheduler and workers to encrypted channels where your network policy requires it, and document who owns the certificate renewal process.

Shorten session lifetimes

A Google sign-in does not end when a user leaves the company unless the Airflow session also expires or is revoked. Set a session lifetime that matches your policy for privileged tools, and make the Google Workspace account suspension the single point where access is removed. Test that a suspended Google account cannot start a new Airflow session and that existing sessions end within the window you set. Record the configured values so auditors can see them.

Keep a local break-glass admin

Once Google is the only login, an outage at Google, a misconfigured redirect URI or a lost Workspace admin account can lock every operator out. Keep one named local admin account with a long, vaulted password and a hardware-backed second factor where the FAB setup allows it, and disable local login for everyone else. Test the break-glass path before go-live, store its credentials under dual control, and alert when it is used. Confirm with your platform team how local login is enabled and disabled in your chosen auth configuration.

Set least-privilege default roles

Users created at first Google login receive the role set by AUTH_USER_REGISTRATION_ROLE, and that default should be the lowest role that still lets a user see their work. Avoid mapping any Google account to Admin by default, including accounts from the domain owner's group. Review every AUTH_ROLES_MAPPING entry for roles that grant more than read access, and document which teams may trigger, edit or pause DAGs. Revisit the defaults whenever you add a new role or team.

Review who holds Admin

Admin in Airflow can change connections, variables and users, so the list of Admin holders is a control in its own right. Run a recurring review that compares Airflow Admin assignments with the approved owners in your identity records, and remove any account that no longer needs the role. Because Google does not send groups in the default flow, confirm where Admin assignments are maintained, since manual changes in Airflow can drift from what your access review shows.

Log every role change

Role assignments and removals should leave a record that someone outside the platform team can read. Confirm which role changes Airflow writes to its logs, forward those logs to your central logging system, and set alerts for any change to Admin or to AUTH_ROLES_MAPPING. Store the reviewed configuration in version control so each change has an author and an approval. Ask your compliance lead which retention period applies to these records, since that depends on your own policy.

Common Google sign-in failures and their causes

This table lists the sign-in and role problems teams most often hit when wiring Google OAuth into the FAB auth manager, with the likely cause and the fix for each. Read it by symptom: find what the user sees, check the cause column against your OAuth client and webserver_config.py, then apply the fix before changing anything else.

Symptom	Likely cause	Fix
Google shows a redirect URI mismatch error	The authorized redirect URI in the Google Cloud OAuth client does not exactly match the callback URL Airflow sends, including scheme, host, port and path	Copy the callback URL from your running Airflow and enter it exactly as an authorized redirect URI, then retest in a private browser window
Only internal users can be selected, or external users are blocked	The OAuth consent screen is set to External when the workforce is all in your Workspace domain, or set to Internal without the intended users being in the organization	Set the user type to Internal for a Workspace-only deployment, and confirm the consent screen settings match who needs access
Users from outside the company can sign in	No domain check is configured in the Google OAuth flow or in the custom security manager, so any Google account can complete sign-in	Restrict accepted accounts to your primary domain in code and confirm with a test account from another domain that login is refused
New users land with the default role instead of the expected one	AUTH_ROLE_PUBLIC or the default role for newly registered users is set too broadly, or Google does not send group data so no mapping rule matches	Set the default to the least-privileged role, assign real roles through an explicit mapping or a manual step, and check the role on a fresh test login
Role changes in Google do not appear in Airflow	AUTH_ROLES_SYNC_AT_LOGIN is off, so roles are set once at first login and not refreshed on later sign-ins	Enable AUTH_ROLES_SYNC_AT_LOGIN, confirm the mapping logic reads the right claims, then sign out and back in to verify the change
Login loops back to the Google sign-in page after a URL change	The public base URL, callback path or session cookie settings changed, so the redirect URI and the session no longer match the new address	Update the base URL setting and the Google redirect URI together, clear cookies for the old host, and test the full flow over HTTPS

Questions buyers ask before setting up Google sign-in

How much effort does Airflow login with Google Workspace take?

The effort depends mostly on how many roles you need and whether roles come from Google groups or are assigned by hand. A small set of roles assigned to individual users is a short configuration task. Mapping several roles from group membership, with role sync at every login and a tested default role for new users, takes more design and more testing. Your Google Cloud governance also matters: if the OAuth consent screen, domain restriction and project ownership already have an approval process, that process adds steps. Ask any partner to price the work from a written list of roles, the group model, and the number of environments (for example, staging and production), not from a generic hour estimate.

Can an in-house team set up Google sign-in without a partner?

Often yes, if the team already runs Airflow 3 and understands the FAB auth manager. The FAB provider handles Google OAuth through webserver_config.py, and the configuration itself is well documented. The harder parts are the Google Cloud project setup, the decision about who may register, and testing that a user outside your domain is refused. Teams with no recent OAuth experience, or with strict change control, often bring in a partner for the design and validation steps and keep the rest in-house. Confirm your own skills against the provider documentation before deciding.

What do Google Workspace and Airflow admins need to provide?

The work needs two sets of people. On the Google side, an administrator needs to create or choose the Google Cloud project, configure the OAuth client and its authorized redirect URLs, and confirm the domain that users must belong to. On the Airflow side, an administrator needs to set the auth manager options, decide the role mapping and default role, and keep a local break-glass admin account available for recovery. Both teams should agree on who owns the client secret, where it is stored, and who approves changes to the role mapping.

How long does it take to validate Google sign-in?

Validation time depends on the number of test cases and on how long your change process takes, not on a fixed number of days. At minimum, test a user from the allowed domain, a user from outside it, a user in each mapped role, a user with no mapped role, and a first-time login under the default role. Test the same cases in staging before production. Ask your partner or internal owner to list each test case with its expected result and to record the evidence, so the sign-off is repeatable. No duration figure is supplied for this work, so confirm the timeline in writing against your own environment.

Can Airflow use Google groups directly for role mapping?

Not in the way many teams expect. FAB maps identity provider groups or roles to Airflow roles through AUTH_ROLES_MAPPING, and the Google OAuth flow does not send group membership by default in the way some other providers do. Where Google does not send groups, you typically map roles by another method, such as a directory lookup, an approved list of users, or a separate identity layer that exposes groups as claims. Confirm with the FAB provider documentation and your Google Workspace setup exactly what claims are available before you commit to a group-based design.

What recurs after Google sign-in goes live?

Several things recur. Airflow 2 reached end of life on April 22, 2026 and gets no fixes, and Airflow 3 has ongoing patch releases, so the FAB provider and Airflow version need periodic upgrades and regression testing of login. Your role mapping needs review whenever teams change, and access reviews should confirm that users who left the domain or changed roles no longer have access. Client secrets and redirect URLs need rotation and checks. Ask any partner whether these tasks are included in a support retainer or billed separately.

Who is responsible for Google sign-in security after go-live?

Your organization stays responsible for who can sign in and what they can do. The Airflow operator owns the auth manager settings, the role mapping and the break-glass account. The Google Workspace administrator owns domain membership, user lifecycle and the OAuth client. Access reviews should be recorded, and changes to the mapping should go through change control. DeployOpen can plan, configure, test and document this setup and support it under a retainer, but auditors and certification bodies, not DeployOpen, issue any assessment or attestation.

What should a quote for Google sign-in include?

A useful quote lists the scope in writing: the roles to map, the default role for new users, the environments covered, the test cases, the documentation delivered and the handover to your team. It should separate one-time design and configuration from any recurring support, upgrades and access reviews. Ask which parts depend on your Google Cloud governance and which depend on your Airflow deployment. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the quote follows from that written scope.

How DeployOpen scopes the Google sign-in work

DeployOpen plans and implements Google sign-in for Airflow inside your own infrastructure, on the Airflow host, container platform or virtual machines you operate. The written scope fixes what gets built: the webserver_config.py settings for the FAB Google OAuth provider, the Google Cloud OAuth client and its redirect configuration, the domain restriction, the role mapping for users whose Google token carries no group data, the default role assigned to new users, and the break-glass path for administrators. Scope, deliverables and timelines are agreed in writing before any work starts, and a quote follows directly from that document. Ask for the quote to name each of these items separately so you can see which ones your own team could take over.

Testing and documentation of the role model are part of the written scope, not an optional extra. Testing should cover a user from your domain who signs in for the first time, a user from outside the domain who should be refused, a user whose role changes and is picked up at the next login, and a user whose access should end. The documentation should record each role, what it permits, how it is assigned and who approves changes to it, so that your administrators can run the model after handover. Before you sign, confirm with DeployOpen which test environments and which Google Workspace accounts the tests will use, since those determine how close the tests come to production.

Ongoing support is available as a retainer, and that is the right place to plan for changes that arrive after go-live. Airflow and the FAB provider both release updates, and Google may change how it issues tokens or how your Workspace administrators manage groups. A retainer can cover re-testing after upgrades and reviews of role assignments. Ask whether the retainer includes the Google Cloud project and OAuth client upkeep, and who holds the credentials for them, because those are the parts most likely to break quietly.

How DeployOpen delivers Airflow identity integrations

DeployOpen plans, implements, tests and documents Google sign-in for Airflow inside your own infrastructure, as part of a self-hosted open-source platform. The work starts with a written scope that fixes what access rules, role mapping and login behavior are covered before any configuration begins.

How we scope

Confirm which Google Workspace domains may sign in and how unknown accounts are handled.
Agree how roles are assigned when Google does not send group membership to Airflow.
Set the default role for new users and the named administrators who keep access.

How we build

Configure the FAB auth manager's google OAuth provider in webserver_config.py for your deployment.
Set up domain restriction and role mapping, and test each role against real Google accounts.
Keep a break-glass admin path and verify it works before cutover.

How we hand over

Deliver the configuration, OAuth client settings and secret locations with written runbooks.
Document the role model, who approves access changes and how to revoke a user.
Walk your platform and security teams through login testing and the recovery steps.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.
Ongoing support, upgrades and continuous testing are available as a retainer.
Confirm with your team how Airflow upgrades will be retested against the Google sign-in setup.

Apache Airflow login with Google Workspace