How Airflow 3 signs in through AWS IAM Identity Center
The Amazon provider's AWS auth manager uses AWS IAM Identity Center for authentication and Amazon Verified Permissions for authorization, and its documentation marks it alpha and experimental, subject to change without warning. If your team already runs workforce access through Identity Center and wants Airflow logins to follow the same directory, this is the path you are evaluating. Treat it as a design choice you must re-test on every Airflow and provider upgrade, not as a settled production standard. Confirm the current status in the AWS auth manager documentation before you commit to it.
Every Airflow auth manager exposes a token endpoint, usually POST /auth/token. The UI receives its token in an httponly cookie named _token, so browser scripts cannot read it directly. When a token expires, the auth manager refreshes it through its refresh_user method where that method is supported, so ask the provider team to confirm refresh behavior for the AWS implementation during your proof of concept. Test a session that runs past token expiry, and test a revoked user, because those are the cases where sign-in and authorization can disagree.
Airflow 3 allows only one auth manager at a time, selected through the auth_manager option, so the AWS auth manager replaces the Simple auth manager and the FAB auth manager rather than running beside them. That makes a break-glass path a planning item from day one. Decide before go-live how an administrator signs in if Identity Center or Verified Permissions is unavailable, and confirm with your own environment how that account is kept outside the normal sign-in flow.
What you need before enabling the AWS auth manager
The AWS auth manager depends on a supported Airflow 3 baseline, the Amazon provider package, two AWS services and a reachable, TLS-protected API server. Confirm each item below before you change the auth_manager setting, because a gap in any one of them stops sign-in rather than degrading it.
Airflow 3 baseline
Start from the current Airflow 3 patch line, which is 3.3.2 at the time of writing, and confirm your Python version falls within the supported range of 3.10 to 3.14. Airflow 2 reached end of life on April 22, 2026, so an older base is not a safe starting point for a new identity integration. Check the version you actually deploy against the version support table before you build.
Metadata database
Use PostgreSQL or MySQL as the metadata database. The SQLite default is for testing only, and MariaDB is not supported as the metadata database. Plan for the database to hold the state of every run and session the auth flow depends on, and confirm the PostgreSQL version (14 to 18) or MySQL version (8.0, 8.4 or an Innovation release) against the prerequisites page.
Host sizing
Allow at least 4 GB of RAM for the components you run, which the prerequisites recommend as a minimum. The API server now serves the UI and the auth endpoints, so size it separately from the scheduler and DAG processor. Ask your platform team to confirm CPU and memory for the API server under expected sign-in volume before you pick instance types.
Amazon provider package
Install the Amazon provider package that includes the AWS auth manager, and pin it against your Airflow version. Provider releases move independently of the core, so do not assume a pairing from memory. Confirm the exact provider version that matches your Airflow 3 patch in the Amazon provider documentation, then record it in your constraints file.
IAM Identity Center instance
Provide an IAM Identity Center instance that will authenticate Airflow users, along with the users and groups who should reach each Airflow role. Confirm which identity source the instance uses, whether that is the built-in directory or an external provider, and who in your organization administers the application assignment. Decide up front how group membership will map to Airflow permissions.
Verified Permissions policy store
Create an Amazon Verified Permissions policy store that holds the schema and policies Airflow uses for authorization. Plan who can change policies, how changes are reviewed, and how the store is recovered if it is altered by mistake. The auth manager is marked experimental, so keep the policy definitions in version control so you can reproduce them after an upgrade.
Network and TLS for the API server
Expose the API server on an HTTPS URL that your users and the AWS redirect flow can reach. Confirm the public base URL, the certificate chain and the DNS name before you configure the redirect and callback addresses, since a mismatch between these values is a common cause of failed sign-in. Restrict inbound access to the networks your staff use and confirm that the API server can call AWS endpoints from your VPC.
Configuring the three setup areas in order
The sequence builds the sign-in path, the authorization model and the Airflow settings in an order that lets each layer be tested before the next one depends on it. The result is an Airflow API server that authenticates through IAM Identity Center and authorizes each view through Amazon Verified Permissions.
Register Airflow as an Identity Center application
A platform engineer creates an application in IAM Identity Center for the Airflow UI and records the sign-in and redirect settings that the Amazon provider documentation describes for this auth manager. Confirm each value against the provider's current documentation before you enter it, because the auth manager is marked alpha and experimental and its settings can change without warning. The step is done when the application exists, its identifiers are saved in your configuration inventory, and an administrator can start a sign-in from the Identity Center portal.
Assign users and groups to the application
An identity administrator assigns the people and groups who need Airflow access to the application in Identity Center. Tie assignments to groups that your directory or HR process already maintains, so that joiners and leavers change access without manual edits in Airflow. Decide now which group should hold administrative rights, because the authorization policies in the next steps depend on those group names. The step is done when each intended group appears as assigned and a test account from each group is listed under the application.
Create the Verified Permissions policy store
A security or platform engineer creates an Amazon Verified Permissions policy store for Airflow authorization. Confirm the Region and account requirements in the provider documentation, and record the policy store ID, because the Airflow configuration needs it to request authorization decisions. Limit write access to the store to the administrators who own Airflow permissions, since any change there alters what every Airflow user can see. The step is done when the store exists, its ID is saved, and its permissions are restricted to a named owner group.
Load the Airflow policy schema and test policies
Load the schema that the Amazon provider documents for Airflow resources and actions into the policy store, then write a small first set of policies for the groups assigned in step two. Keep the first set narrow: one group with broad rights, one group limited to read-only views, and no blanket policy that grants every action to every principal. Use the policy store's testing tools with sample principals to check that each group receives the decisions you intended. The step is done when the schema validates and each test principal receives the expected allow or deny result for each view.
Set auth_manager and the AWS settings in Airflow
A platform engineer sets the
auth_manageroption to the AWS auth manager class, then adds the AWS settings for the Identity Center application, the policy store and the Region, using the option names in the Amazon provider documentation. Airflow 3 allows only one auth manager at a time, so remove any Simple or FAB auth manager setting from the same configuration. Apply the change to the API server and restart it so the new settings load. The step is done when the API server starts without auth manager errors and the sign-in page redirects to Identity Center.Verify token issuance and view-level access
Sign in as a test user and confirm that the auth manager's token endpoint issues a token, usually at POST /auth/token, and that the UI stores it in an httponly cookie named
_token. Repeat the test from the Identity Center portal to confirm that IdP-initiated sign-in also lands in Airflow. Then sign in as one test user from each group and confirm that each user sees only the views the policies permit, with denied pages returning an authorization error. Where the auth manager supports it, let a token expire to confirm the refresh path. The step is done when every test result matches your policy matrix and the results are saved as change evidence.
How the Verified Permissions policy store schema maps to Airflow permissions
The policy store schema is the model that tells Amazon Verified Permissions what exists in your Airflow deployment and what each identity may do with it. It defines entity types for users, groups and Airflow resources, along with the actions that can be applied to those resources. When Airflow asks whether a signed-in user can perform an action, such as viewing a DAG or triggering a run, the auth manager sends the principal, the action and the resource to the policy store and acts on the decision it receives. The schema is therefore the contract between your identity groups and Airflow's permission model. Copy the schema from the Amazon provider documentation rather than writing your own names, because the auth manager expects the entity types and action identifiers that the provider defines. Confirm the exact schema version against the provider release you install, since the auth manager is marked experimental and its documentation says it may change without warning.
Before rollout, store the schema, the policy statements and any changes to them in version control, and review every change through the same approval path you use for Airflow configuration. Treat each policy change as a permission change: a broader statement can grant access to DAGs or connections that users never had before. Build a test set of expected decisions, covering an admin, an operator, a read-only user and a user in no group, and run those checks against a non-production policy store before any change reaches production. Record which groups map to which actions, so an auditor or incident responder can trace a denied or allowed action back to a specific policy. Plan for drift: if someone edits the policy store in the console, the version-controlled copy becomes wrong, so restrict console write access and reconcile the two on a fixed schedule. Ask your implementation partner or your own team to document the test cases alongside the policies so that they survive staff changes.
Mapping Identity Center groups to Airflow permissions
This table shows how Identity Center groups and user attributes could map to Verified Permissions principals and Airflow access levels, with an owner for each change. The rows are illustrative because the exact policy store schema and entity names must be confirmed against the Amazon provider documentation and your own design. Use it as a starting model for a review with your identity and Airflow owners before any policy is written.
| Identity Center source | Policy store entity (illustrative) | Airflow resource or action | Change owner (illustrative) |
|---|---|---|---|
| Group: airflow-platform-admins | Group principal mapped to an Admin role | Full access to Connections, Variables, Pools and DAG management | Head of data platform, with CISO sign-off |
| Group: airflow-pipeline-operators | Group principal mapped to an Operator role | Trigger, pause and clear DAG runs for assigned teams | Data engineering lead |
| Group: airflow-analysts-readonly | Group principal mapped to a Viewer role | Read DAG and task status and logs, no run actions | Analytics manager |
| User attribute: team or cost center | Attribute on the user principal used in a policy condition | Restrict DAG-level actions to DAGs tagged for that team | Identity administrator, with the team owner |
| Identity Center group membership | Verified Permissions principal resolved from the token | Confirm that group claims in the token match the policy store entity names | Identity administrator |
| Break-glass admin account | Separate principal with a narrowly scoped admin policy | Emergency access when Identity Center is unavailable, stored and audited | CISO, with documented approval for each use |
| Policy store schema change | Entity types and actions added or renamed | Any change to permitted Airflow actions, tested in staging first | Security architect, with a change record |
Whether IdP-initiated SSO works and what to test
IdP-initiated sign-in means a user starts from the IAM Identity Center user portal, selects the Airflow application, and arrives in the Airflow UI without first visiting the Airflow login page. The more common path is service-provider-initiated sign-in, where Airflow sends the browser to Identity Center for authentication. The AWS auth manager documentation in the Amazon provider describes the sign-in flow, but the portal launch path depends on how the application is registered in Identity Center and which callback address Airflow accepts. The AWS auth manager is marked alpha and experimental and may change without warning, so do not assume the portal launch path behaves the same after a provider or Airflow upgrade. Confirm it in your own environment against the provider documentation before you promise it to users. Amazon provider: AWS auth manager
Run the redirect checks with a test user in a non-production Airflow. Start from the Identity Center portal and confirm the browser lands on the Airflow UI, not on an error page or in a loop back to Identity Center. Check that the callback address in the Identity Center application matches the address Airflow expects, character for character, including scheme, host and path. Then repeat the test with a user who has no group or Verified Permissions assignment for Airflow and confirm that the user is refused. Open the browser developer tools and confirm that the session token is set as an httponly cookie named _token, so page scripts cannot read it. Also confirm that the token endpoint, usually POST /auth/token, is called once and that the session is established without a second sign-in prompt.
Then test the session lifecycle. Keep a session open until its token expires and confirm that Airflow refreshes it through the auth manager's refresh_user method, where the provider supports refresh, and does not keep a stale session with old permissions. Next, disable the test user in Identity Center and measure how long the user can keep using an open Airflow session. The window depends on token lifetime and refresh behavior, so record what you observe and ask AWS and the provider documentation for the expected window before you write it into an access procedure. Finally, test sign-out from Airflow and from the Identity Center portal separately, since ending one session may not end the other. Keep the results as evidence for your access review, and repeat these checks after every Airflow or provider upgrade.
Hardening the experimental integration
The AWS auth manager is alpha and can change without warning, so the controls below assume that the sign-in path, the policy store and the browser session will all need attention over time. Each card names one control to put in place before users depend on the integration and one thing to check on every upgrade.
Pin the provider version
The AWS auth manager ships in the Amazon provider package, so its behavior changes when that package changes. Pin the Amazon provider version in your constraints file and promote upgrades through staging like any other dependency. Before each upgrade, read the provider changelog for auth manager settings, schema expectations and token behavior, and test sign-in, role checks and token refresh against a copy of your policy store.
Restrict who can edit the policy store
Authorization decisions live in the Amazon Verified Permissions policy store, so anyone who can change its policies or schema can change who runs and edits which DAGs. Limit write access to a small set of IAM principals, separate them from the people who manage Airflow day to day, and enable CloudTrail logging for Verified Permissions API calls. Review the policy store contents on a fixed schedule and compare them with the role design you approved.
Keep a break-glass path outside AWS
If IAM Identity Center or the policy store is unavailable or misconfigured, administrators can be locked out of Airflow entirely. Keep a documented recovery route that does not depend on the AWS auth manager, such as a separate auth manager configuration prepared in advance, or a controlled administrative path to the metadata database. Store the procedure with your incident runbooks, test it in staging, and confirm who may invoke it and how the use is logged.
Protect the _token cookie
The UI receives its token in an httponly cookie named _token, so the browser session is only as safe as the transport that carries it. Serve the API server only over HTTPS, terminate TLS with current protocol settings, and confirm that the cookie is set with the Secure flag in your deployment. Shorten session lifetimes where your policy requires it, and check that your reverse proxy does not strip or rewrite the cookie.
Watch for breaking changes
Because the feature is subject to change without warning, a working setup can break after an Airflow or provider release even if your own configuration is unchanged. Subscribe to the Airflow and provider release notes, keep a test environment with the same identity provider and policy store as production, and run a sign-in, token refresh and permission check suite before every upgrade. Record which Airflow and provider versions you have validated so that rollback targets are known.
Questions to answer before choosing this auth manager
Is the AWS auth manager production ready given its experimental status?
Treat it as a pilot choice for now. The Amazon provider documentation marks the AWS auth manager as alpha and experimental and says it is subject to change without warning, so a login flow or policy behavior you depend on could shift in a provider upgrade. Before you place it in front of operators, ask who owns regression tests for each provider release, which provider version you will pin, and how you will roll back if a release changes sign-in or authorization. Many teams keep a supported auth manager ready as a fallback until the provider documentation changes its status. Read the current AWS auth manager documentation and confirm the status with the Airflow community before you approve a production date.
When is FAB the safer choice than the AWS auth manager?
FAB is the safer choice when you need a sign-in path that your change board can approve today. Airflow 3 uses the Simple auth manager by default, allows only one auth manager at a time through the auth_manager option, and the FAB auth manager comes from the FAB provider. Choose FAB if your identity provider already has a working FAB integration in your team, if your operators depend on established role mapping, or if the experimental label blocks your approval. Choose the AWS option only if IAM Identity Center and Amazon Verified Permissions are already your standard, and you can fund the testing that an experimental component requires. Confirm the FAB provider version that matches your Airflow 3 release before you compare the two options.
What drives the effort of an AWS auth manager setup?
Effort follows three setup areas, and each one can grow with your organization's identity design:
- Identity Center setup: the application, users and groups, attribute mapping and how sign-in is initiated from the portal.
- Policy store design: the Amazon Verified Permissions schema, the policies that map groups to Airflow permissions, and how DAG-level access is modeled.
- Testing: sign-in, sign-out, token expiry, permission checks for each role, and repeat tests after every provider upgrade.
The number of groups, the number of DAG teams, and how many environments you run all widen the policy work. Ask any partner or internal lead for a written breakdown of these three areas, the environments in scope, and the test cases they will run before accepting a fixed scope.
What must your team provide before setup starts?
Three roles need to be available early, and missing one of them usually stalls the work:
- AWS account owners who can create or approve the resources in the accounts where Airflow runs and where the policy store will live.
- An IAM Identity Center administrator who can create the application, manage users and groups, and approve attribute mappings.
- An Airflow administrator who can set the
auth_manageroption, edit the deployment configuration, and test role access on a non-production environment.
You should also name a person who approves the policy design and a person who owns the test results. Ask whether these roles will be filled by your staff or by an outside team, and get the access requirements in writing before the scope is signed.
Can an in-house platform team set up the AWS auth manager alone?
An in-house team can do it if three conditions hold. Its members already run Airflow 3 in production, they know IAM Identity Center and Amazon Verified Permissions well enough to design a policy store, and they can keep a test suite running through every provider upgrade. The experimental status makes the last condition the hardest one, because the work does not end at go-live. If one of these conditions is missing, a short pilot with an outside team can establish the baseline, document the configuration, and hand over the tests. DeployOpen plans, implements, documents and supports self-hosted platforms in your own infrastructure under a written scope, so you can choose between a full build, a handover, or ongoing support. Compare the options with a written scope from each provider.
How does token refresh work when refresh_user is not supported?
Each auth manager provides a token endpoint, usually POST /auth/token, and the UI receives its token in an httponly cookie named _token. When a token expires, the auth manager refreshes it through its refresh_user method where that method is implemented. If the AWS auth manager in your version does not support refresh_user, a user whose token expires will need to sign in again, so the session length and the lifetime of the token become the operational settings to check. Test what an operator sees at expiry, how long a DAG run monitor stays usable, and whether automation that calls the API needs a separate credential. Confirm the behavior for your provider version in the Airflow auth manager documentation before you set user expectations.
Why sign-in or authorization fails after setup
This table pairs common failures with the likely cause and a verifiable check or fix for the AWS auth manager. Work through it in order: confirm the auth manager is the only one configured, then check the token cookie, the refresh path, and the policy store before changing identity settings.
| Symptom | Likely cause | Check or fix |
|---|---|---|
| Login succeeds but the UI shows no session | Token not set in the _token cookie, often because the browser blocks it or the request is not served over the expected host and scheme | Inspect the response from the token endpoint (usually POST /auth/token) and confirm a Set-Cookie header for _token with httponly. Check the cookie domain and whether the UI and API share a host. |
| Session ends after a set period and users are sent back to login | Refresh failing after token expiry, so the refresh_user method cannot renew the token | Check the API server logs for errors on the refresh path. Confirm the IAM Identity Center application is still assigned to the user and that the session lifetime matches your configuration. |
| Users authenticate but see access denied on pages or DAGs | Authorization decision denied in Amazon Verified Permissions, because the user or group entity is missing or lacks the expected action | Use the policy store to test the principal and action pair for the failing page. Confirm group membership in Identity Center is reflected in the entities the auth manager sends. |
| Authorization errors appear after a configuration change to the policy store | Policy store schema does not match the schema the provider expects, so entity types or actions are not recognized | Compare the deployed schema with the one in the Amazon provider documentation for the installed version. Reapply the schema to a test policy store before changing the production one. |
| Airflow starts but login behaves like the Simple auth manager or FAB | A second auth manager is set or left over, while Airflow allows only one through the auth_manager option | Check the auth_manager value in the configuration and in environment variables such as AIRFLOW__CORE__AUTH_MANAGER. Remove any extra auth manager settings and restart the API server. |
| Sign-in redirects fail or loop with an IdP error | Application or redirect settings in IAM Identity Center do not match the Airflow host, or the flow started from an unexpected entry point | Confirm the Airflow URL configured in the Identity Center application and the callback path the auth manager uses. Test with a direct sign-in from the Identity Center portal to separate IdP-initiated from Airflow-initiated flows. |
| Behavior changes after a provider package upgrade | The AWS auth manager is alpha and experimental and may change without warning | Pin the Amazon provider version in your build, read its release notes before upgrading, and test sign-in and authorization in staging first. |
When FAB is the safer choice for Airflow 3
The FAB auth manager is the safer choice when you need a login path that is not marked experimental. FAB comes from the FAB provider rather than the Amazon provider, and it has a longer footprint in Airflow 2 deployments. Its OAuth and LDAP integrations are the ones most teams have already run, and the behavior of its role mapping is documented and widely exercised. The AWS auth manager, by contrast, is marked alpha and experimental in the Amazon provider documentation and may change without warning. Treat that label as a planning input: a change to token handling or policy schema could force a rework of your access model during a routine provider upgrade.
FAB is also the better fit when you already have role mappings you rely on. If your Airflow 2 installation maps directory or identity provider groups to Admin, Op, Viewer and custom roles through AUTH_ROLES_MAPPING, moving those rules into Amazon Verified Permissions means rebuilding the policy store schema, the entity model and the group-to-role logic, then testing every DAG-level permission again. That work is real, and it is not a one-time cost if your group structure changes often. Before deciding, list your current mappings, count the DAG-level permissions in use, and ask who will maintain the Verified Permissions policies after go-live.
The trade-off runs both ways, so do not treat FAB as the default without checking. FAB sits on the Airflow 2-era model, and some of your environment may need to match the AWS-native sign-in pattern, such as IAM Identity Center being your only identity source. Confirm with the Amazon provider and Airflow documentation which auth manager your target Airflow 3.3.2 deployment supports for the features you need, and test your chosen path in a non-production environment before you commit. Whichever you choose, keep a break-glass administrator account that does not depend on the identity provider.
How DeployOpen scopes and delivers this integration
DeployOpen plans and delivers the AWS auth manager for Airflow inside your own AWS accounts and network, so IAM Identity Center sign-in and Amazon Verified Permissions authorization are designed around your access model. The work is agreed as a fixed scope in writing before it starts, and each stage ends with deliverables your team can review and run.
How we scope
- The written scope names which Airflow 3 environments, AWS accounts and IAM Identity Center instances the auth manager will cover.
- We document the three setup areas, the policy store schema and the role model your teams need before any configuration starts.
- The scope states that the Amazon provider's AWS auth manager is alpha and experimental, and records how that risk is accepted or excluded.
How we build
- We configure the Airflow auth manager settings, IAM Identity Center application and Amazon Verified Permissions policy store in a non-production environment first.
- We test IdP-initiated sign-in, token issuance through the auth manager's token endpoint and session refresh against your real user groups.
- We compare the AWS auth manager results with the FAB auth manager option, so the decision to proceed is documented rather than assumed.
How we hand over
- You receive configuration, policy definitions and a runbook covering each setup area, the schema and the steps to add or remove users.
- We document the known limits of the experimental provider, including what to re-test after each Amazon provider or Airflow upgrade.
- Handover includes a verification checklist your security and platform teams can repeat in their own environment without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover re-validation when the experimental provider changes.
- Support can include reviewing Airflow upgrade notes and Amazon provider releases that affect authentication before your teams apply them.
- Any change to the written scope, such as a new environment or a move to FAB, is agreed in writing before the work begins.
