If you've recently upgraded to Apache Airflow 3 and logged into the webserver, you may have noticed something different about how login and permissions work. Gone is the Flask-AppBuilder (FAB) based login system that powered Airflow 2. In its place is the Simple Auth Manager, the new default authentication and authorization system for Airflow 3.
This guide explains what Apache Airflow is for readers who are new to it, what an auth manager does, how the Simple Auth Manager works, how to configure it, and what you need to know before relying on it, especially in production.
What Is Apache Airflow?
If you're brand new to Airflow, here's the short version: Apache Airflow is an open-source platform used to author, schedule, and monitor workflows. A "workflow" in Airflow is called a DAG (Directed Acyclic Graph), which is essentially a series of tasks with dependencies between them, written as Python code. Data engineers commonly use Airflow to orchestrate things like ETL pipelines, machine learning training jobs, and routine data syncs between systems.
Because Airflow has a web-based UI where you can view, trigger, and monitor these workflows, it needs a way to control who can log in and what they're allowed to do once they're in. That's where an auth manager comes in.
What Is an Auth Manager?
An auth manager is the component in Airflow responsible for two things:
- Authentication — verifying who a user is (usually via username and password, or an external identity provider)
- Authorization — determining what that user is allowed to see and do once logged in
Airflow's auth manager system is pluggable, meaning you can swap in different implementations depending on your needs. You could use one built around your company's identity provider, for example, or write a custom one. The Auth Manager documentation covers the full interface and the available options.
What Is the Simple Auth Manager?
The Simple Auth Manager is the auth manager that comes by default in Airflow 3. As its name suggests, its logic and implementation are intentionally simple. It replaces FabAuthManager, the default in Airflow 2, as part of a broader effort to remove the FAB dependency from Airflow's core and make the authentication layer pluggable.
The intended usage of the Simple Auth Manager is only for development and testing purposes, and it should not be used in production. It's deliberately limited in scope: it doesn't support flexible role definitions or custom mappings between roles and capabilities. If you need a production-grade authentication setup, Airflow supports other pluggable auth managers, including ones built around cloud identity providers, and you can write your own using the auth manager interface.
The full official reference for this feature lives in the Simple Auth Manager documentation.
How User Management Works
Unlike FAB, which stored users and roles in Airflow's metadata database, the Simple Auth Manager is fully config-controlled and doesn't touch the database at all. Users are defined directly in your Airflow configuration file (airflow.cfg), or via environment variables.
Here's the basic format:
[core]
simple_auth_manager_users = "bob:admin,peter:viewer"
The list of users is comma-separated, and each user is a username/role pair separated by a colon. In the example above:
- bob is assigned the admin role
- peter is assigned the viewer role
Passwords Are Auto-Generated
You'll notice the configuration only specifies usernames and roles, not passwords. That's intentional. Passwords are auto-generated for each user and printed in the webserver logs. Once generated, they're saved to a file set by core.simple_auth_manager_passwords_file, which defaults to $AIRFLOW_HOME/simple_auth_manager_passwords.json.generated. You can open that file and read (or manually update) the passwords if needed.
If you're running Airflow through Breeze (Airflow's local development environment) for local development, two users come predefined out of the box: admin and viewer, each with a password matching their username.
A common gotcha: setting environment variables like AIRFLOW__SIMPLE_AUTH_MANAGER__USERNAME and PASSWORD won't reliably let you pre-seed a specific password. Since Airflow generates a random password on startup by default, this trips up a lot of people trying to force a known password this way. If you need deterministic credentials, editing the generated passwords file directly after startup is currently the more dependable route.
Roles and Permissions
The Simple Auth Manager doesn't let you create custom roles or fine-tune permission mappings. There's no option to manage roles and permissions; they're defined as part of the implementation and can't be modified. There are four fixed roles:
| Role | Permissions |
|---|---|
| Viewer | Read-only access to Dags, assets, and pools |
| User | Viewer permissions, plus full edit, create, and delete permissions on Dags |
| Op | User permissions, plus full permissions on pools, assets, config, connections, and variables |
| Admin | All permissions |
This is a deliberate tradeoff. Rather than giving you the granular role-based access control (RBAC) that FAB offered, the Simple Auth Manager sticks to four broad tiers that are easy to reason about and hard to misconfigure, at the cost of flexibility.
Multi-Team Support
If you're running Airflow for multiple teams sharing a single environment, the Simple Auth Manager supports basic team-based resource isolation. When multi-team mode is enabled, users can be associated with one or more teams, and teams restrict which resources (DAGs, connections, variables, pools) a user can access.
Enable it with:
[core]
multi_team = True
Then assign teams to users by adding a third colon-separated field, with multiple teams separated by a pipe character:
[core]
multi_team = True
simple_auth_manager_users = "bob:admin:team1|team2,peter:viewer:team1,alice:op:team2"
In this example, bob is an admin with access to both team1 and team2, peter is a viewer restricted to team1, and alice is an op restricted to team2.
A couple of details worth flagging:
- Resources that aren't explicitly assigned to a team are treated as global and remain accessible to everyone, including team-restricted users.
- Admins bypass team restrictions entirely. You can still assign an admin to a team, but it has no practical effect since admins already have access to everything.
Disabling Authentication Entirely
For fast local development or throwaway testing environments, the Simple Auth Manager offers an option to skip authentication altogether. This lets anyone who accesses the Airflow UI automatically log in as an admin with full permissions.
You enable it like this:
[core]
simple_auth_manager_all_admins = "True"
This is convenient when you're spinning up a local instance just to test a DAG, but it should never be used anywhere reachable outside your own machine.
Generating a JWT Token for the API
Airflow 3's public REST API is JWT-based, and the Simple Auth Manager provides the endpoint that issues those tokens. To generate one, send a POST request with your username and password:
ENDPOINT_URL="http://localhost:8080"
curl -X 'POST' \
"${ENDPOINT_URL}/auth/token" \
-H 'Content-Type: application/json' \
-d '{
"username": "<username>",
"password": "<password>"
}'
You can then include the returned token in subsequent API requests. If simple_auth_manager_all_admins is enabled, you can generate a token without providing any credentials at all. For more detail, see the Simple Auth Manager token guide and the token API reference.
Key Things to Keep in Mind
It's not built for production. This is the single most important thing to understand. The Simple Auth Manager exists to give Airflow 3 a working, dependency-light default so the core project could drop its hard reliance on FAB. If you're deploying to production, you should either configure a different auth manager or make sure access to your Airflow environment is locked down through other means (network isolation, a reverse proxy with its own auth layer, VPN access, and so on).
No database, no dynamic role editing. Everything lives in your configuration file. That makes it simple to version-control and reason about, but it also means you can't add or edit roles without changing the auth manager implementation itself.
Passwords are ephemeral by default. Since Airflow generates them fresh unless you intervene, plan for how you'll retrieve or fix credentials, particularly in containerized or ephemeral environments like Docker Compose or Kubernetes, where logs might not be easy to inspect after the fact.
Multi-team isolation isn't full multi-tenancy. It's resource-level filtering based on team assignment, not a hard security boundary. Global (unassigned) resources are visible to everyone, so don't rely on it as your only access control layer.
Switching auth managers later is a heavy lift. If you start with the Simple Auth Manager and later move to a production-grade option, all users, roles, and permissions need to be recreated in the new system. It's worth deciding early if the Simple Auth Manager is only a placeholder for you or a long-term fit.
Frequently Asked Questions
Is Simple Auth Manager safe to use in production?
No. It's explicitly intended for development and testing only. For production, use a different auth manager and control access through additional layers like network isolation or a reverse proxy.
Where do I find my auto-generated password?
Check the webserver logs on startup, or look in the file set by core.simple_auth_manager_passwords_file (default: $AIRFLOW_HOME/simple_auth_manager_passwords.json.generated).
Can I create custom roles in Simple Auth Manager?
No. Only four fixed roles exist: Viewer, User, Op, and Admin. Custom roles require a different auth manager.
How do I disable login entirely for local testing?
Set simple_auth_manager_all_admins = "True" under [core] in your Airflow configuration. Everyone who accesses the UI will be logged in as an admin automatically.
Wrapping Up
The Simple Auth Manager is Apache Airflow's answer to needing a lightweight, dependency-free authentication system out of the box for Airflow 3. It's easy to configure, requires no database, and gets you up and running in minutes with config-defined users and four fixed roles. But its simplicity is also its boundary: no custom roles, no dynamic user management, and an explicit warning against production use. If you're evaluating Airflow 3 for a real deployment, treat the Simple Auth Manager as your development sandbox and plan your production authentication strategy separately.
For more on Airflow's authentication options, see the official Auth Manager documentation and Airflow Security guide.
Top comments (0)