Skip to content

Validate id_token issuer and audience in the FAB Authentik provider - #72645

Merged
vincbeck merged 1 commit into
apache:mainfrom
potiuk:security/fab-authentik-claims-validation
Sep 9, 2026
Merged

vincbeck merged 1 commit into
apache:mainfrom
potiuk:security/fab-authentik-claims-validation

Conversation

@potiuk

@potiuk potiuk commented Sep 7, 2026

Copy link
Copy Markdown
Member

The authentik OAuth path in the FAB auth manager decoded the id_token
without any claims_options, so authlib validated only the time-based
claims. Neither the issuer nor the audience was checked.

A provider signs the tokens of every application registered with it using a
single key set, so a valid signature only establishes that the provider
minted the token — not that it was minted for Airflow. A token issued for a
different application registered with the same provider was accepted and
authenticated its subject as an Airflow user.

This pins:

  • aud to the configured client_id
  • iss to the issuer advertised in the provider's OpenID metadata

If no issuer can be resolved, verification now fails with an actionable
error rather than falling back to an audience-only check — the configured
key set may sign for more than one issuer, so an audience-only check would
still accept a token from an untrusted one. Deployments whose metadata does
not publish an issuer can set it explicitly in the provider's
client_kwargs; this is documented.

This mirrors the claims_options already applied on the azure path in the
same file.

Tests

Six tests covering a correctly addressed token, a token for another
application, a token from another issuer, the fail-closed path (asserted
with a correct audience and a wrong issuer, which is the shape an
audience-only fallback would let through), and the configured-issuer
override both accepting a valid token and rejecting a foreign issuer.

The three rejection tests fail without the source change.


Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)

Generated-by: Claude Code following the guidelines

The authentik OAuth path decoded the id_token with no claims_options, so
authlib validated only the time-based claims. The issuer and audience were
never checked.

A provider signs the tokens of every application registered with it using
one key set, so a valid signature only establishes that the provider minted
the token, not that it was minted for Airflow. A token issued for a
different application registered with the same provider was therefore
accepted, and authenticated its subject as an Airflow user.

Pin the audience to the configured client_id and the issuer to the value
advertised in the provider's OpenID metadata. When no issuer can be
resolved, verification fails closed with an actionable error instead of
falling back to an audience-only check: the key set may sign for more than
one issuer, so an audience-only check would still accept a token from an
untrusted one. Deployments whose metadata omits the issuer can set it
explicitly in the provider's client_kwargs.

This mirrors the claims_options already applied on the azure path in the
same file.

Tests cover a correctly addressed token, a token for another application, a
token from another issuer, the fail-closed path asserted with a correct
audience and a wrong issuer, and the configured-issuer override both
accepting a valid token and rejecting a foreign issuer.
@potiuk
potiuk force-pushed the security/fab-authentik-claims-validation branch from ec1f8ae to 87f62dd Compare September 7, 2026 18:24
@vincbeck
vincbeck merged commit d1acf31 into apache:main Sep 9, 2026
79 checks passed
imrichardwu pushed a commit to imrichardwu/airflow that referenced this pull request Sep 11, 2026
…pache#72645)

The authentik OAuth path decoded the id_token with no claims_options, so
authlib validated only the time-based claims. The issuer and audience were
never checked.

A provider signs the tokens of every application registered with it using
one key set, so a valid signature only establishes that the provider minted
the token, not that it was minted for Airflow. A token issued for a
different application registered with the same provider was therefore
accepted, and authenticated its subject as an Airflow user.

Pin the audience to the configured client_id and the issuer to the value
advertised in the provider's OpenID metadata. When no issuer can be
resolved, verification fails closed with an actionable error instead of
falling back to an audience-only check: the key set may sign for more than
one issuer, so an audience-only check would still accept a token from an
untrusted one. Deployments whose metadata omits the issuer can set it
explicitly in the provider's client_kwargs.

This mirrors the claims_options already applied on the azure path in the
same file.

Tests cover a correctly addressed token, a token for another application, a
token from another issuer, the fail-closed path asserted with a correct
audience and a wrong issuer, and the configured-issuer override both
accepting a valid token and rejecting a foreign issuer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants