How authentik fits behind Cloudflare Access as the identity provider
If you already use Cloudflare Access for application access and want authentik to be the system of record for users and groups, the integration works like this: authentik is added as an OpenID Connect login method in Access, and the group claims authentik sends in the token are what Access policies match against. Access decides who may reach an application, authentik decides who a user is and which groups they belong to. The authentik side uses the OAuth2/OpenID Connect provider described in the authentik Cloudflare Access integration guide, so the work is split between an authentik application and provider on one side and an identity provider configuration in Cloudflare Zero Trust on the other.
Keep the traffic path separate from the login path. Cloudflare Tunnel and its connector, *cloudflared*, carry requests from Cloudflare's network to your origin. cloudflared makes outbound-only connections and has no inbound listener on the origin, so it does not handle identity at all. authentik is not in the request path for application traffic either; it is only contacted during login and token issuance. Before you change anything, confirm which hostnames route through the tunnel, which Access applications protect them, and which group names your policies currently reference, because those are the values you will need to keep stable when authentik takes over the directory role. Check the group claim name and format in your authentik provider configuration against what your Access policies expect, and test with a non-production user first.
Plan ownership before the first login. Someone must own the authentik application and its group structure, and someone must own the Access policies that consume those groups, and a change to a group name in authentik can silently lock users out of an application. Decide which system holds the policy definitions in the long run. If you manage Access with the Cloudflare Terraform provider, the Access applications, policies, identity providers and tunnels are declared as code, which makes group-name changes reviewable. Confirm the plan and account limits for your Cloudflare One account against your number of applications and policies, since the Cloudflare One account limits cap Access applications and reusable policies per account.
What you need before you connect authentik to Access
Four things have to be in place before the login method works: a supported authentik version, a Cloudflare One account on a plan that fits your scale, an issuer URL that Cloudflare can reach over valid TLS, and a group model that authentik can emit as claims. The cards below cover each one, plus the connector that carries traffic to your origin.
Target a supported authentik line
Plan the deployment on the 2026.8.x line, which the authentik security policy lists as receiving security fixes alongside 2026.5.x. The GitHub releases page shows 2026.8.4 as the latest release, so pin to a specific patch and confirm it again on the day you build. Check the release notes for any change to OIDC provider settings before you copy configuration from an older deployment. Record the exact version in your change ticket so upgrades can be sequenced later.
Confirm the Cloudflare One plan
Access is part of Cloudflare One, and the Zero Trust plans page offers a free plan for a proof of concept but does not list per-user prices. Ask Cloudflare sales which tier includes the Access features, identity provider limits and support level you need, and get the quote in writing. Include any SASE packaging you may be asked to bundle, because it changes the cost without changing the authentik setup. Confirm the account limits that apply to your size before you design the application catalog.
Publish a reachable authentik issuer
Cloudflare Access must fetch the OpenID Connect discovery document and keys from your authentik issuer URL, so that URL must resolve publicly and present a certificate chain that Cloudflare trusts. Confirm the issuer hostname, the reverse proxy in front of authentik, and the renewal process for the certificate. An internal-only hostname will pass a local test and then fail at the first Access login. Write down the exact issuer URL and the client ID you will register, since both must match later.
Design the group claims first
Access policies can match on group values sent in the token, so decide the group names and their scope in authentik before you touch the Access side. Keep one group per access decision, such as a team that needs a specific application, and avoid nesting logic you cannot explain to an auditor. Confirm which claim name Access will read and that authentik includes it in the token for the users who need access. Test a group change with one user before you rely on it for production policies.
Plan the outbound-only connector
If the protected applications sit on private networks, cloudflared runs on the origin network and opens outbound-only connections to Cloudflare, so no inbound listener is required on the origin. It is open source under Apache-2.0, and the current release is 2026.10.1. Treat it as version-controlled software: pin the version, schedule updates, and monitor the tunnel health. Confirm the host, the firewall egress rules and the replica count before go-live.
Decide how Access config is managed
Access applications, policies, identity providers and groups can be created in the dashboard or managed as code. The Cloudflare Terraform provider, at v5.28.0 under Apache-2.0, covers Access applications, policies, groups and identity providers, along with tunnels and routes. Choose one method before the first deployment, because mixing dashboard edits with managed resources causes drift. Confirm that your team can review and roll back the change set in the same way it handles other infrastructure.
Configure the authentik OIDC provider and the Access login method
This sequence connects authentik to Cloudflare One as an OpenID Connect login method, passes group claims into Access policies, and confirms that only members of the intended group get through. The result is an Access application that signs users in through authentik and enforces group-based rules.
Create the OAuth2/OIDC provider in authentik
An administrator in authentik creates an OAuth2/OpenID Connect provider for Cloudflare Access, using the integration guide in the authentik integrations catalog as the reference. Set the redirect URI to the callback value that Cloudflare One shows for its OpenID Connect login method, and include the groups scope so group membership is returned in the token. Confirm the scope list before saving, because a missing groups scope is the most common reason policies later see no groups.
Create the authentik application and assign groups
Create an application in authentik that uses the new provider, and bind it to a group that will hold the users allowed into the Cloudflare-protected application. Apply a binding or policy so that only members of that group can use the application, and keep a separate test group for the later check. Record the group name exactly as it appears in authentik, since Access policies will match on it.
Record the issuer and client details
Copy the issuer URL, client ID and client secret from the authentik provider, and confirm the issuer URL matches the OpenID Connect discovery document for the provider. Store the client secret in your secrets manager rather than in a shared document, and restrict who can read it. The output is a verified set of values ready to enter in Cloudflare One.
Add the OpenID Connect login method in Cloudflare One
In Cloudflare One, add an OpenID Connect identity provider and enter the authentik issuer, client ID and client secret. Confirm the redirect URI shown by Cloudflare matches the one configured in authentik, then save. Use the Cloudflare One button to test the login method so you know the provider handshake works before any application depends on it. The check is a successful test that returns to Cloudflare without an error.
Map the groups claim to Access policies
Open the Access application that protects your internal service and create an Allow policy that matches the authentik group by name through the groups claim. Make sure the group claim reaches Access, and verify the group names match exactly, including case. Keep the policy narrow and avoid a broad Allow rule that includes all authenticated users. The output is a policy that refers to authentik groups rather than individual email addresses.
Confirm the group claim in a test session
Sign in as a non-admin test user who belongs to the intended group, and open the protected application in a private browser window. Check that Access grants the session and that the identity details for the session show the expected groups claim. This confirms the group claim flows from authentik through the login method into Access, which is the core dependency for every later policy.
Test denial for a user outside the group
Sign in as a non-admin user who is not in the authorized group and try the same protected application. Access should deny the request at the policy stage, and the denial should appear in the Access logs with the reason. If the user gets through, review the policy rule order and the groups claim before going further. The sequence is complete once both the allow and deny tests behave as written.
Keep Access with authentik or switch to authentik outposts
This path suits organizations that already rely on Cloudflare for application access across many internal sites, SSH and private network routes. Cloudflare Tunnel with cloudflared keeps the origin reachable only through outbound connections, and Access applies policies at Cloudflare's edge. authentik stays in place as the identity provider, so users keep one login source and group membership still drives who can reach what.
- Edge policy enforcement: Access evaluates every request before it reaches the origin, so applications do not need their own login logic.
- Group claims: authentik sends group membership in the OpenID Connect token, and Access policies match on those groups.
- Tunnel model: cloudflared makes outbound-only connections, so the origin needs no inbound listener from the internet.
- Existing Cloudflare investment: teams already managing Access, Gateway and tunnels avoid running a second access layer.
- Scale limits: confirm current Access application, policy and identity provider counts against your planned footprint in the Cloudflare One account limits.
Before committing, check your plan with Cloudflare, because pricing for Zero Trust features is not listed per user on its public plans page and needs a sales conversation.
This path suits a small set of web applications that already sit behind their own reverse proxy and need authorization decided in authentik. The proxy outpost runs next to those applications and checks each request against authentik policies, so Cloudflare is no longer in the access path. The trade-off is that your team now owns the outpost, its certificates, its upgrades and its availability.
- Fewer moving parts for a few apps: you remove the Cloudflare dependency for applications that do not need a global edge.
- Policy in one place: access rules stay in authentik, next to the same groups and flows used for other sign-ins.
- Extra runtime to operate: the outpost is a component you deploy, monitor and upgrade alongside the authentik server and worker.
- Proxy-specific setup: the configuration depends on your reverse proxy, which is covered in the forward auth topic.
- Failure domain: if the outpost or its connection to authentik fails, access to protected applications is affected.
Confirm that your reverse proxy and network design can reach authentik reliably before you retire Access for any application.
The decision often turns on how many applications, hostnames and policies you need to manage. Cloudflare publishes account limits for Access applications, reusable policies, rule groups, identity providers and tunnels, and some of these can be raised on Enterprise accounts. Teams should compare their expected growth against those limits before choosing a design that will be costly to reverse.
- Application inventory: count current and planned Access applications and reusable policies, not only today's protected sites.
- Identity providers and tunnels: check the identity provider and tunnel counts you expect to run.
- Enterprise limits: ask Cloudflare whether your required limits need an Enterprise account.
- Infrastructure as code: the Cloudflare Terraform provider can manage Access applications, policies, groups and tunnels, which reduces drift at higher counts.
- Drift between systems: keep the authentik group names and the Access policy references in sync through a single source of truth.
Ask Cloudflare to confirm current limits for your account type before you finalize the design.
Whichever path you choose, the operational load differs. With Access, your team manages the Cloudflare configuration, tunnel health and the authentik OIDC provider. With outposts, your team also owns the proxy component, its scaling and its release cadence. Plan both paths against the same operating model so that neither becomes a gap during an incident.
- Release tracking: authentik publishes versions named by year and month, and its security policy lists which versions receive security fixes, so plan upgrades against that list.
- Advance notice: the project announces security releases at least 24 hours in advance, which should be built into your change process.
- Tunnel replicas: cloudflared replicas and their hosts need monitoring, since outbound connections are the only path to the origin.
- Access changes: policy changes made outside code are hard to audit, so keep them in version control where possible.
- Runbooks: document how to restore access if authentik or the chosen enforcement point is unavailable.
Write these checks into the design review so the chosen path has a named owner for each component.
How authentik claims map to Access policy rules
This table traces one login from the authentik side to the Access policy side, showing which user attribute or group claim each rule depends on. Read it top to bottom when building or debugging a policy, and check each row against the integration guide and your own provider settings, since claim names and group filters can differ by release.
| Element | Where it is set | What Access receives or evaluates | What to confirm before go-live |
|---|---|---|---|
| User email | authentik user profile and the OIDC provider's scope settings | Email claim used for Access include rules on specific addresses or domains | Confirm the email claim is emitted for your provider and matches the address users actually sign in with |
| Name | authentik user profile | Display name shown in Access logs and session records | Confirm the claim name in the integration guide; name is informational and rarely used in rules |
| Subject identifier | authentik provider, generated per user | Stable unique identifier for the user, independent of email changes | Confirm which claim Access uses as the user identity so renamed or re-addressed users keep their history |
| Groups claim | authentik OIDC provider scope mapping, using the groups attribute of each user | List of group names the user belongs to, available to Access group rules | Confirm the claim name and that the groups scope is included in the provider configuration |
| Group name match | authentik group name and Access group rule value | Access grants or denies only when the strings are identical | Compare names character by character, including case and spacing, because a mismatch fails silently as a denial |
| Include rule | Access policy, Include section | Allows access when the chosen claim or group matches | Test with one known user per group before widening the rule to a whole team |
| Exclude rule | Access policy, Exclude section | Blocks users who match, even if an Include rule matches them | Use for offboarding or contractor carve-outs and confirm the excluded group is populated in authentik |
| Require rule | Access policy, Require section | Every listed condition must hold, such as a required group plus a verified login method | Confirm which login method or device signals Access can enforce with your identity provider configuration |
Hardening the identity path between authentik and Access
Access trusts whatever authentik asserts, so the OIDC client, the redirect URIs, the group claims and the authentik server itself form one chain of trust. Each card below covers one link in that chain and what to verify before go-live.
Store and rotate the client secret
The OAuth2/OIDC client secret that Access uses to talk to authentik should live in a secrets manager or in the Access identity provider configuration only, never in a shared runbook or Terraform state committed to a repository. Plan a rotation date and a second secret overlap window so that a rotation does not lock every user out of Access at once. Confirm who can view or regenerate the secret in both systems, because either side can change it.
Restrict redirect URIs exactly
Register only the callback URL that your Cloudflare Access team domain generates for the authentik provider, and avoid wildcards or extra paths. In authentik, check that the provider accepts only that exact redirect URI so that a crafted link cannot send an authorization response to another host. Review the list after every change to the Access team name or domain.
Limit groups per application
Use the group claim from authentik in Access policies to decide who reaches each application, and write every policy as an explicit allow list rather than relying on a broad default. Keep groups that grant access to sensitive internal tools separate from general staff groups, and confirm which claim name Access reads so that a renamed group does not silently widen or remove access.
Stay on a supported authentik line
authentik's security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Run the authentik server on one of those lines, subscribe to the release feed, and schedule upgrades within the sequential upgrade path before a line drops out of support. Your team should be able to show which version is running and when it was last patched.
Require MFA in authentik
Access can request multi-factor authentication only as far as the identity provider asserts it, so the MFA stage belongs in the authentik flow that Access uses for login. Confirm that the authentication context or amr-style claim you rely on is actually present in the token Access receives, and test with a user who has no second factor enrolled to see how the flow behaves. Enrollment and recovery flows deserve the same scrutiny as sign-in.
Pin cloudflared and the Terraform provider
cloudflared runs as an outbound-only daemon, so it needs no inbound listener on the origin, but it still runs on your hosts and should be pinned to a tested version and updated on a schedule. Pin the Cloudflare Terraform provider version in your lock file, review changes to Access applications and policies in plan output, and keep state access restricted because it can contain sensitive values.
Patch and back up the authentik host
Cloudflare Tunnel avoids inbound listeners on the origin, but it does not patch the authentik server, its worker, or PostgreSQL. Those hosts need operating system patching, container image updates, and tested backups of the PostgreSQL database, because it holds all authentik configuration and data. Confirm restore steps with a test restore, since a lost identity database would stop every Access login.
Common failures when authentik sign-in reaches Access
This table lists the failures most often seen when an authentik login reaches Cloudflare Access, with the likely cause and the first check for each. Work down the rows in order, since a broken redirect or missing claim blocks every later test. Most failures trace back to the OIDC provider settings or the policy that reads the groups claim.
| Failure | Likely cause | First check |
|---|---|---|
| Redirect URI mismatch | The callback URL registered in the authentik OAuth2/OIDC provider does not match the team domain callback that Access sends, often after a team name or hostname change. | Compare the redirect URI in the authentik provider with the callback shown in the Access login method, character for character, including the trailing path and scheme. |
| Groups claim missing, so policies deny everyone | The authentik provider does not include the groups scope or a groups property mapping in the ID token, so Access has no group values to match in its policies. | Sign in as a test user and inspect the ID token claims. Confirm the groups scope is requested and that the mapping is attached to the provider. |
| Group name mismatch | The group names in the Access policy differ from the authentik group names in case, spacing or prefix, or the policy uses a group ID where the claim carries a name. | Copy the exact group value from the token claim and paste it into a test policy. Check whether the claim carries names or identifiers. |
| Clock skew or TLS problems on the issuer URL | The issuer URL does not present a certificate chain Cloudflare trusts, or the authentik server clock drifts so that token timestamps fall outside the accepted window. | Fetch the issuer's OpenID configuration URL from outside your network and check the certificate chain. Confirm the host clock is synchronized with NTP. |
| Tunnel with no healthy replicas | The cloudflared connector behind the tunnel is stopped, cannot reach Cloudflare, or has no active replicas, so the protected application cannot be reached after sign-in succeeds. | Check the tunnel status in the Cloudflare One dashboard and the cloudflared service logs on the origin host. Confirm outbound connectivity from the host to Cloudflare. |
| Policy ordering allows or denies unexpectedly | An earlier Allow or Block policy matches first, or a broad rule above the intended group rule overrides it, so the result differs from the policy the team meant to apply. | List the application's policies in evaluation order and test each one with a known user. Remove or reorder broad rules before changing group values. |
Questions buyers ask before connecting authentik to Cloudflare Access
Is authentik Open Source free to use with Cloudflare Access?
Yes, the Open Source edition of authentik is listed as free, and its repository code sits under the MIT license, so the software itself carries no license fee for an OpenID Connect login method. The costs that remain are the infrastructure to run authentik, the Cloudflare plan that hosts Access, and the people who plan, build and operate the integration. Enterprise features are a separate matter: authentik lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, according to its pricing page. You only need Enterprise if your design depends on a feature listed there, so confirm that before budgeting. Check the license terms in the enterprise directory if you plan to use any of that code.
What does Cloudflare Zero Trust cost for Access?
Cloudflare's Zero Trust plans page offers a free plan that suits a proof of concept, but it does not publish per-user prices for paid tiers and directs packaging that adds WAN and Firewall to sales. Ask Cloudflare for a written quote that names the Access seats, the number of users and any external users, the plan tier, and whether support is included. Your final Access cost depends on your user count, your identity provider count and the add-ons you select, none of which this page can state. Because Access stays on Cloudflare's side, budget for it as a separate line from authentik.
How long does an authentik and Cloudflare Access integration take?
The duration depends mainly on how many Access applications you protect, how many policies and groups you map, and how many people must approve the group design. A single application with one OpenID Connect login method and a few group rules is a small job, while dozens of applications with different allow lists, a tunnel design and a staged cutover take much longer. Cloudflare's account limits allow 500 Access applications and 500 reusable policies per account, so the scale of your existing setup matters. Ask any partner to give a written timeline tied to a fixed scope, listing applications, groups, environments and test cases.
What must our team provide before the integration starts?
You need administrator access to the authentik instance, including rights to create providers, applications, groups and flows, and administrator access to the Cloudflare One account for Access applications, identity providers and policies. A group design must exist before configuration begins, because Access policies match on the group claims that authentik sends. You also need the DNS records and TLS certificates for each protected hostname, the tunnel or origin details for each application, and a named owner who can approve policy changes. Confirm these items with your identity and network teams in writing before scheduling the work.
How do group claims from authentik reach Cloudflare Access policies?
authentik sends group membership in the token or user information it returns after the OpenID Connect login, and Access can match on those values in its policies. The setup requires a scope and claim mapping in authentik that includes group names, plus an Access identity provider that reads them. Group names that differ between directories cause policies to silently allow or deny the wrong people, so test each rule with a representative account for each group. Document the mapping so that auditors and on-call staff can trace an access decision back to an authentik group.
Can a capable internal team build this without a partner?
Yes, a team that already runs authentik and operates Cloudflare Access can build this integration, provided it has time to test and someone who owns the group design. The main risks are not the configuration steps themselves but the policy mistakes that lock out users or expose an application, and those are easier to catch with a second reviewer and a written test plan. A partner adds value when the team lacks authentik or Cloudflare experience, when the application count is high, or when the work must be documented to support a compliance review. DeployOpen plans and implements these integrations inside your infrastructure under a written, fixed scope, so the choice comes down to your skills and schedule.
What breaks most often in this kind of integration?
The most common failures are a redirect URI that does not match the Access callback, an authentik application that is not bound to the right provider, and group claims that are missing or named differently from the policy. Clock skew, expired certificates and a hostname that resolves to the wrong origin also cause confusing login loops. Cloudflare Tunnel connects outward from cloudflared to Cloudflare's network with no inbound listener, so a stopped or unhealthy connector shows up as an unreachable application, not a login error. Check the callback, the claim names and the connector health in that order when troubleshooting.
When should we replace Cloudflare Access with authentik outposts instead?
Keep Access when your applications already sit behind Cloudflare, your policies live in Cloudflare, and you want the edge to enforce identity before traffic reaches your origin. Consider authentik outposts when you want all access decisions and logs inside authentik, when you run applications in your own network that you do not want routed through a third party, or when you need to remove a second policy system. Moving to outposts changes where the proxy runs, how it is upgraded and who monitors it, so plan that work as a migration with its own test plan. Confirm which option fits your data residency and operations model before you change anything in production.
What a DeployOpen engagement covers for this integration
A DeployOpen engagement for this integration starts with a written scope that names the authentik instance, the Cloudflare One account, the Access applications in scope and the identity groups that will drive policy. Deliverables and timelines are agreed in writing before work begins, and the quote follows from that scope. The work covers configuring the OpenID Connect provider in authentik, adding it as a login method in Cloudflare Access, designing the group claims that Access policies will match, and running a test plan that proves allowed users reach each application while denied users, users outside the groups and users with an incomplete MFA result are blocked. Ask us to show the expected allow and deny results for each application before sign-off.
Documentation and handover are part of the fixed scope. The deliverables typically include the authentik provider and application settings, the Access login method configuration, the group-to-policy mapping, the test results and the steps to add a new application or group. If your team manages Cloudflare with infrastructure as code, confirm with us whether the Access configuration should be captured with the Cloudflare Terraform provider, since that decision changes what we hand over. Ongoing support, authentik version upgrades and periodic re-testing of access rules are available as an optional retainer, separate from the fixed-scope build. DeployOpen prepares configuration, controls and evidence for your review, but it does not issue audit reports, attestations or certifications. If an assessor needs independent assurance over these access controls, that assessment comes from an independent auditor or certification body.
