In short

Problem: After I switched on Traefik GeoBlock, Claude’s connector to Home Assistant stopped working, while Home Assistant itself was fine for everyone at home.

Solution: The connector calls from Anthropic’s servers in the US, and GeoBlock only allowed my own countries. One allowedIPAddresses entry with the provider’s published IP range fixed it.

Tested with: Traefik 3, GeoBlock plugin (PascalMinder) 0.3.8, Home Assistant with an MCP server for Claude

In Hardening Traefik I put GeoBlock in front of every service: only visitors from the countries my family lives in get through, everyone else gets a 403. It worked exactly as planned. A bit too well, as it turned out: it also locked out a visitor I wanted, my own AI assistant.

This is a short story about a security measure that does its job, breaks something you need, and how to find out which one it was.

1. The symptom

I use Claude with a connector to Home Assistant, so I can ask about sensors, automations and logs in plain language. Shortly after the hardening, the connector couldn’t reach Home Assistant anymore. Every attempt failed.

At the same time, Home Assistant was perfectly fine: the dashboard loaded at home, the app on my phone worked, automations ran. Only this one client was affected.

2. What I checked first (and why it misled me)

A connector that signs in with OAuth has plenty of parts that can break, so that’s where you look first:

• Sign-in and tokens: an expired token or a broken OAuth setup would explain a failing client. But reconnecting doesn’t help when the requests are blocked before they arrive.
• Home Assistant logs: nothing. No failed login, no error from the MCP integration, not even a request.
• The URL: it opens fine in the browser.

The empty Home Assistant log was the real clue, and it’s easy to read it the wrong way. “No errors” sounded like “nothing wrong in Home Assistant”. It actually meant: the requests never arrived. Something in front of Home Assistant was answering them. And “it works in my browser” proved nothing, because my browser comes from an allowed country.

3. The real cause: Traefik GeoBlock did its job

Claude’s connectors don’t run in my browser or on my phone. They call my server from Anthropic’s infrastructure, which sits in the US. For GeoBlock that’s just another request from a country that isn’t on the list.

Two logs show it. GeoBlock writes every denied request to its own file. A line looks like this (example address):

INFO: GeoBlock: 2026/10/16 09:14:52 geoblock@docker: request denied [203.0.113.17] for country [US] due to: country is not allowed

And the Traefik access log shows the 403 with an empty backend ("-" after the router name). That dash means the request never reached the service (again an example line):

203.0.113.17 - - [16/Oct/2026:09:14:52 +0000] "POST /api/webhook/… HTTP/1.1" 403 0 "-" "-" 4711 "homeassistant@docker" "-" 1ms

The log is full of scanners from all over the world, so the connector’s requests don’t stand out by themselves. Compare the denied addresses with the range Anthropic publishes for its outgoing traffic, and they do.

4. The fix: allow the published IP range

GeoBlock has an option for exactly this: allowedIPAddresses. Addresses in this list are let through no matter which country they come from. One more label on the Traefik container:

      # Claude connectors call from Anthropic's published outbound range
      # source: https://platform.claude.com/docs/en/api/ip-addresses
      - "traefik.http.middlewares.geoblock.plugin.geoblock.allowedIPAddresses[0]=160.79.104.0/21"

Then recreate the container so Traefik reads the new labels:

docker compose up -d traefik

The range above is the one Anthropic lists at the time of writing. Check Anthropic’s IP address page for the current one before you copy it. The same approach works for any other service that has to reach you from abroad, as long as its provider publishes its IP ranges.

5. How to verify

1. Check that Traefik picked up the label:
   docker inspect traefik --format '{{ index .Config.Labels "traefik.http.middlewares.geoblock.plugin.geoblock.allowedIPAddresses[0]" }}'
2. Use the connector once (in my case: ask Claude for a sensor value).
3. Make sure the range no longer shows up as denied:
   grep -E '\[160\.79\.1(0[4-9]|1[01])\.' traefik-logs/geoblock.log | tail
   No new lines after the restart means GeoBlock lets the connector through.

What I learned

• “Works in my browser” is no test for a geo-block. Ask where the failing client really calls from.
• An empty application log is a finding, not a dead end: the request was stopped earlier.
• Before switching on an allow list, write down every service that calls in from outside: AI connectors, webhooks, monitoring, push services. Each one needs a deliberate exception or a different path.

The full GeoBlock and CrowdSec setup is in Hardening Traefik: geo-blocking, CrowdSec and single sign-on.

In short

Problem: Every login through a new Authentik OAuth2/OpenID provider fails with invalid_request: “The request is otherwise malformed”.

Solution: The provider was created through the API, and its grant_types list was empty. Set it to authorization_code and refresh_token, then test the authorize URL with curl.

Tested with: Authentik 2026.8, WordPress with the OpenID Connect Generic plugin 3.11

I add most apps to Authentik through the admin interface. For this blog I wanted to script it, so I created the OAuth2 provider with a single API call. The call succeeded, the application showed up, the WordPress plugin was configured with the right client ID, secret and endpoints. And then not a single login worked.

The fix turned out to be one field. Finding it took longer than it should have, because the error message points in the wrong direction.

1. The symptom: “request is otherwise malformed”

Clicking “Login with OpenID Connect” in WordPress sent me to Authentik, and Authentik sent me straight back with an error page instead of a login form:

invalid_request
The request is otherwise malformed

No username prompt, no password prompt. Authentik refused the request before the login flow even started.

2. What I checked first (and why it misled me)

“Malformed request” sounds like the client sent something wrong. So I went through the usual suspects on the WordPress side:

• Redirect URI: character by character against the provider. Authentik uses strict matching, so a missing slash or a different query string is enough to break it. It matched.
• Client ID: copied again, no stray spaces.
• Scopes: openid email profile, all three available in the provider.
• Endpoints: taken from the provider’s .well-known/openid-configuration.

Everything was correct. The request from WordPress was fine. The problem was on the Authentik side, and the browser error doesn’t tell you that.

3. The real cause: an empty grant_types list

The Authentik server log had the more useful message. With Docker Compose:

docker compose logs server --since 10m | grep -i grant

It said “Invalid grant_type for provider”. Every OAuth2 provider in Authentik has a list of allowed grant types. When you create a provider in the admin interface, the form fills in sensible defaults. The API doesn’t: grant_types is an optional field, and if you leave it out, the provider is saved with an empty list. An empty list means no grant type is allowed, so not even the normal authorization code flow works.

My API call looked roughly like this (shortened):

curl -X POST https://id.example.com/api/v3/providers/oauth2/ \
  -H "Authorization: Bearer $AUTHENTIK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Provider for My Blog",
    "client_type": "confidential",
    "authorization_flow": "<flow uuid>",
    "invalidation_flow": "<flow uuid>",
    "redirect_uris": [
      {"matching_mode": "strict",
       "url": "https://blog.example.com/wp-admin/admin-ajax.php?action=openid-connect-authorize"}
    ],
    "signing_key": "<certificate uuid>",
    "property_mappings": ["<openid>", "<email>", "<profile>"]
  }'

Every required field is there, so the API accepts it without a warning. The one field that decides whether anyone can log in is the one that’s missing.

4. The fix

Set the grant types on the existing provider. A login flow for a website needs authorization_code, and refresh_token if the app renews its tokens:

curl -X PATCH https://id.example.com/api/v3/providers/oauth2/<provider id>/ \
  -H "Authorization: Bearer $AUTHENTIK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"grant_types": ["authorization_code", "refresh_token"]}'

You can also open the provider in the admin interface and save it there with both grant types ticked. For new providers, add the line straight to the create call:

    "grant_types": ["authorization_code", "refresh_token"],

While you’re at it, compare the token lifetimes too (access_token_validity, refresh_token_threshold) with a provider you created in the interface. API-created providers don’t always get the same values, and it’s easier to keep all providers alike.

5. How to verify (without a browser)

You don’t need to click through the login to test a provider. Call the authorize endpoint with curl and look at where Authentik sends you:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  "https://id.example.com/application/o/authorize/?client_id=<client id>&response_type=code&scope=openid&redirect_uri=https%3A%2F%2Fblog.example.com%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize"

• Working: a 302 to Authentik’s own login flow, for example /if/flow/default-authentication-flow/….
• Broken: a 302 back to your app’s redirect URI with error=… in the URL. The error name tells you what Authentik didn’t like.

What I learned

• “Malformed request” in the browser doesn’t mean the client is wrong. Read the identity provider’s server log before you change anything in the app.
• The admin interface and the API don’t create the same object. The interface fills in defaults, the API stores exactly what you send.
• A curl test of the authorize URL checks a provider in seconds, without logging in.

How the blog login is set up end to end is in Single sign-on for WordPress with Authentik. All provider fields are described in the official Authentik documentation.

In short

Problem: As soon as ports 80 and 443 are open, bots from all over the world scan your services, try passwords and probe for known vulnerabilities. Traefik alone forwards all of it.

Solution: Several layers in front of every service: geo-blocking for countries you never visit from, CrowdSec for known attackers and attack patterns, single sign-on in front of apps without their own good login, plus a few container basics.

Tested with: Traefik 3.7, GeoBlock plugin 0.3.8, CrowdSec 1.8 with the Traefik bouncer plugin 1.7 and AppSec, Authentik 2026.8, Docker Compose on a small home server

This is the second part of my Traefik setup. The first part explains the basics: entrypoints, routers, labels and certificates. Here it’s about the question Traefik itself doesn’t answer: should this request get in at all? A reverse proxy decides where a request goes. The layers in this article decide whether.

The layers at a glance

Every request to port 443 passes these checks in order. Each one is cheap, and each one stops a different kind of visitor:

No single layer is perfect. GeoBlock is fooled by a VPN, CrowdSec doesn’t know every attacker, and every login can have a bug. Together, they turn “anyone on the internet” into “a few people, in a few countries, with a valid login”.

1. One line for all services

You could add middlewares to every router separately. I attach the two global ones to the websecure entrypoint instead, in Traefik’s static configuration. That way no service can be forgotten, including the ones I add next year:

    command:
      # ... the configuration from part 1 ...

      # Security for EVERY site on 443: first GeoBlock, then CrowdSec, then security headers (step 5).
      # To switch both off quickly: comment out this line and run docker compose up -d
      - "--entrypoints.websecure.http.middlewares=geoblock@docker,crowdsec@docker,secheaders@docker"

      # The two plugins, downloaded from plugins.traefik.io at start
      - "--experimental.plugins.geoblock.modulename=github.com/PascalMinder/geoblock"
      - "--experimental.plugins.geoblock.version=v0.3.8"
      - "--experimental.plugins.crowdsec.modulename=github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin"
      - "--experimental.plugins.crowdsec.version=v1.7.1"

• The order matters: GeoBlock runs first because it’s the cheapest check. Requests from blocked countries never reach CrowdSec, which keeps its logs and work small.
• @docker means the middleware is defined with Docker labels, here on the Traefik container itself (next sections).
• Plugin versions are pinned, for the same reason as the Traefik image in part 1: a new plugin version can change options.
• Port 80 is not covered, and that’s fine: it only answers with a redirect to HTTPS, which then passes every check.

2. GeoBlock: only the countries you need

My services are used by my family, all of us in two European countries. There’s no reason for anyone in other countries to reach my login pages. GeoBlock looks up the country of each visitor’s IP address and only lets the allowed ones through. These labels go on the Traefik container:

    labels:
      # --- GeoBlock: only allow listed countries (+ private/home IPs) ---
      - "traefik.http.middlewares.geoblock.plugin.geoblock.countries[0]=DE"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.countries[1]=AT"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.allowLocalRequests=true"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.allowUnknownCountries=false"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.unknownCountryApiResponse=nil"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.blackListMode=false"

      # Exceptions: a service that has to reach you from abroad
      - "traefik.http.middlewares.geoblock.plugin.geoblock.allowedIPAddresses[0]=203.0.113.0/24"

      # Country lookup
      - "traefik.http.middlewares.geoblock.plugin.geoblock.api=https://get.geojs.io/v1/ip/country/{ip}"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.apiTimeoutMs=750"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.cacheSize=100"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.forceMonthlyUpdate=true"

      # Logging: only denied requests, into their own file
      - "traefik.http.middlewares.geoblock.plugin.geoblock.silentStartUp=false"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.logLocalRequests=false"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.logAllowedRequests=false"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.logApiRequests=false"
      - "traefik.http.middlewares.geoblock.plugin.geoblock.logFilePath=/var/log/traefik/geoblock.log"

• countries: the allowed countries as two-letter codes. Mine are different; pick your own. With blackListMode=false this is an allow list: everything not listed is blocked. The opposite (block a few countries, allow the rest) protects much less.
• allowLocalRequests=true: private addresses (your home network) are always allowed. Without it, you lock yourself out at home as soon as a request arrives with a local address.
• allowUnknownCountries=false: if the lookup finds no country, the request is blocked. Safer, at the price of a rare false block.
• allowedIPAddresses: exceptions for services that call you from another country. In my case that’s an AI assistant’s connector to Home Assistant, which comes from the provider’s published IP range in the US. Only allow ranges the provider publishes officially, never a guessed one.
• Lookup and cache: unknown IP addresses are looked up with an online service (geojs.io here), at most 750 ms. The last 100 results are cached, so repeat visitors don’t cause new lookups.
• Log file: every blocked request ends up in geoblock.log. It’s surprisingly instructive to read it after a day: most of it is automated scanning.

Let’s Encrypt still works with GeoBlock on. The TLS challenge from part 1 is answered by Traefik before any middleware runs, so the validation servers abroad aren’t blocked.

3. CrowdSec: known attackers and attack patterns

CrowdSec does two things. It reads Traefik’s access log and notices when an IP address behaves like an attacker (many failed logins, scanning for /wp-login.php on a server without WordPress, and so on). And it shares this with a community list, so you also block addresses that attacked someone else yesterday. In addition, its AppSec component works as a web application firewall (WAF): it checks each request against rules for common attacks before Traefik forwards it.

There are two parts: the CrowdSec engine (its own container) and a bouncer inside Traefik that asks the engine about every request.

The engine

  crowdsec:
    image: crowdsecurity/crowdsec:v1.8.1
    container_name: crowdsec
    restart: unless-stopped
    environment:
      # Detection rules: Traefik log parser, common web attacks, known CVEs, AppSec (WAF)
      COLLECTIONS: "crowdsecurity/traefik crowdsecurity/base-http-scenarios crowdsecurity/http-cve crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules"
      # Registers the Traefik bouncer with the key from .env
      BOUNCER_KEY_traefik: ${CROWDSEC_BOUNCER_KEY}
      TZ: Europe/Berlin
    volumes:
      - ./crowdsec/config:/etc/crowdsec
      - ./crowdsec/data:/var/lib/crowdsec/data
      - ./crowdsec/acquis.d:/etc/crowdsec/acquis.d:ro
      - ./traefik-logs:/var/log/traefik:ro
    networks:
      - proxy
    # No published ports: Traefik reaches it as crowdsec:8080 and crowdsec:7422

• Collections are rule bundles from the CrowdSec hub: a parser for Traefik’s log format, scenarios for typical web attacks and known vulnerabilities (CVEs), and the AppSec rule sets.
• BOUNCER_KEY_traefik registers Traefik as a bouncer with a key you choose. Create one and put it in the .env file next to the compose file, never in the compose file itself: echo "CROWDSEC_BOUNCER_KEY=$(openssl rand -hex 32)" >> .env.
• Traefik’s log folder is mounted read-only, so CrowdSec can read the access log from part 1.
• No published ports: only Traefik talks to CrowdSec, through the shared proxy network.

What CrowdSec reads is defined in crowdsec/acquis.d/traefik.yaml:

# 1. Traefik access log: brute force, scans, known exploits
filenames:
  - /var/log/traefik/access.log
labels:
  type: traefik
---
# 2. AppSec (WAF): Traefik sends every request here before passing it on
source: appsec
name: appsec
listen_addr: 0.0.0.0:7422
appsec_config: crowdsecurity/appsec-default
labels:
  type: appsec

The bouncer in Traefik

    labels:
      # --- CrowdSec bouncer ---
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.enabled=true"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecMode=stream"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecLapiScheme=http"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecLapiHost=crowdsec:8080"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecLapiKey=${CROWDSEC_BOUNCER_KEY}"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.updateIntervalSeconds=60"
      # AppSec (WAF)
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecAppsecEnabled=true"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecAppsecHost=crowdsec:7422"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecAppsecFailureBlock=true"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.crowdsecAppsecUnreachableBlock=false"
      # never ban the home network
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec.clientTrustedIPs[0]=192.168.10.0/24"

• crowdsecMode=stream: the bouncer downloads the full list of blocked addresses every 60 seconds and checks requests locally. That’s fast, and Traefik doesn’t have to ask CrowdSec for each request.
• crowdsecAppsecFailureBlock=true: if AppSec can’t decide about a request (an error in the check), the request is blocked.
• crowdsecAppsecUnreachableBlock=false: if the CrowdSec container is down, requests are let through. That’s a deliberate trade-off: during a CrowdSec update, my services stay online and GeoBlock still filters. If you’d rather be offline than unprotected, set it to true.
• clientTrustedIPs: your home network is never banned. Without it, a family member typing the wrong password five times can lock out the whole house.

Everyday commands

# which addresses are blocked right now, and why?
docker exec crowdsec cscli decisions list

# what was detected recently?
docker exec crowdsec cscli alerts list

# is the log being read, are the bouncer and AppSec talking to CrowdSec?
docker exec crowdsec cscli metrics

# unblock an address (e.g. a friend who got banned)
docker exec crowdsec cscli decisions delete --ip 198.51.100.7

# block an address by hand for 24 hours
docker exec crowdsec cscli decisions add --ip 198.51.100.7 --duration 24h

The access and GeoBlock logs grow every day, so I rotate them with logrotate on the host (7 days, compressed). copytruncate keeps the file in place, so neither Traefik nor CrowdSec needs a restart:

# /etc/logrotate.d/traefik
/path/to/traefik/traefik-logs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

4. Single sign-on in front of apps

Some apps have no login of their own, or a weak one: Traefik’s dashboard, the Zigbee2MQTT frontend, small admin tools. For those, Traefik asks my identity provider Authentik before every request: is this person logged in, and allowed to use this app? If not, they see Authentik’s login page, with two-factor authentication. This is called forward auth.

The middleware is defined once, with labels on the Authentik server container:

    labels:
      # Embedded outpost path (needed for forward auth on other domains)
      - traefik.http.routers.authentik-outpost.rule=HostRegexp(`.+`) && PathPrefix(`/outpost.goauthentik.io/`)
      - traefik.http.routers.authentik-outpost.priority=1000
      - traefik.http.routers.authentik-outpost.entrypoints=websecure
      - traefik.http.routers.authentik-outpost.tls=true
      - traefik.http.routers.authentik-outpost.service=authentik

      # Forward-auth middleware for apps WITHOUT their own login
      - traefik.http.middlewares.authentik.forwardauth.address=http://authentik-server:9000/outpost.goauthentik.io/auth/traefik
      - traefik.http.middlewares.authentik.forwardauth.trustForwardHeader=true
      - traefik.http.middlewares.authentik.forwardauth.authResponseHeaders=X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid

• The outpost router catches the path /outpost.goauthentik.io/ on every host name and sends it to Authentik. That’s where the login redirect comes back to. priority=1000 makes sure it wins against the app’s own router.
• forwardauth.address: Traefik asks this URL about every request. Authentik answers “yes” (the request continues) or with a redirect to the login page.
• authResponseHeaders: after a successful login, Authentik passes the user name, groups and e-mail to the app as headers. Apps that understand them can log the user in automatically.

Protecting an app is then one more label on its router, here for the Traefik dashboard from part 1:

      - "traefik.http.routers.traefik.middlewares=authentik@docker"

In Authentik, each protected app needs a Proxy Provider in forward-auth mode (single application) and an application that is bound to the users or groups allowed in. Without that, Authentik doesn’t know the host name and refuses everyone.

5. Security headers for every service

Security headers are short instructions that the server sends to the browser with each page. Many apps set some of them, but rarely all, and every app does it differently. A third middleware on the entrypoint adds the important ones to every service and removes the headers that only tell attackers which software and version you run. These labels go on the Traefik container, and the entrypoint line from step 1 gets a third entry: geoblock@docker,crowdsec@docker,secheaders@docker.

    labels:
      # --- Security headers for every site on 443 ---
      # HSTS: browsers use https only, for 1 year
      - "traefik.http.middlewares.secheaders.headers.stsSeconds=31536000"
      - "traefik.http.middlewares.secheaders.headers.contentTypeNosniff=true"
      # Hide software names and versions (an empty value removes the header)
      - "traefik.http.middlewares.secheaders.headers.customResponseHeaders.Server="
      - "traefik.http.middlewares.secheaders.headers.customResponseHeaders.X-Powered-By="

• HSTS (stsSeconds): after the first visit, the browser refuses to open the site over plain HTTP for one year, even if someone tries to redirect it there in a public Wi-Fi. I left out includeSubdomains and preload on purpose: they also bind every other subdomain of your domain to HTTPS, and preload is very hard to undo.
• contentTypeNosniff: the browser trusts the declared file type and doesn’t guess. That stops an uploaded “image” from being run as a script.
• Removing Server and X-Powered-By: before, my services told everyone things like Server: nginx or X-Powered-By: PHP/8.5. That doesn’t make anything vulnerable, but it saves an attacker the first step of looking up exploits for exactly that version.

Checking takes one command per service. You should see strict-transport-security and x-content-type-options, and no server line:

curl -s -o /dev/null -D - https://app.example.com/ | grep -i -E "strict-transport|x-content-type|^server|x-powered"

6. Container basics

A few small settings on the containers themselves, which cost nothing:

  traefik:
    image: traefik:v3.7
    security_opt:
      - no-new-privileges:true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # ...

• no-new-privileges: processes in the container can’t gain more rights later (for example through a setuid program). If someone ever breaks into Traefik, this makes the next step harder.
• Docker socket read-only: Traefik only needs to read container information. Be aware that :ro only protects the socket file; the Docker API behind it still accepts commands. A stricter solution is a socket proxy, a small container that only lets through the read requests Traefik needs. I use one for my monitoring portal and plan to switch Traefik to it too.
• No published ports on any service except Traefik (80 and 443). Everything else is only reachable through Traefik and therefore through all the layers above. A forgotten ports: line bypasses all of them.
• exposedbydefault=false from part 1 belongs here too: nothing is public by accident.

7. Testing that it works

Don’t trust a security setup you haven’t tested. These checks take five minutes. Run the attack tests from outside your home network (mobile data, not Wi-Fi), because your home network is on every allow list:

# AppSec should block typical attack requests with 403
curl -s -o /dev/null -w "%{http_code}n" "https://app.example.com/?id=1%27%20OR%20%271%27=%271"
curl -s -o /dev/null -w "%{http_code}n" "https://app.example.com/../../etc/passwd"
curl -s -o /dev/null -w "%{http_code}n" "https://app.example.com/.env"

# did CrowdSec see it?
docker exec crowdsec cscli alerts list | head

# GeoBlock: requests from other countries show up here
tail -n 5 traefik-logs/geoblock.log

# forward auth: without a login you should be sent to Authentik (302)
curl -s -o /dev/null -w "%{http_code} %{redirect_url}n" https://traefik.example.com/

To test GeoBlock from another country, use a VPN with an exit in a blocked country, or one of the many online “check website from another location” services. You should get a 403.

What I don’t do (yet)

• Central frame and content policies (X-Frame-Options, Content Security Policy): they depend too much on each app, so the apps set them themselves (see step 5).
• Custom TLS options: not needed for me. I checked with openssl s_client: Traefik’s defaults already refuse TLS 1.0 and 1.1 and only accept 1.2 and 1.3.
• Rate limiting: Traefik’s ratelimit middleware on login pages. CrowdSec covers most of it by banning brute-force attempts.
• The socket proxy for Traefik, as mentioned above.

What I learned

• Entrypoint middlewares beat per-router middlewares: new services are protected from their first second, without me remembering anything.
• Allow lists beat block lists. Listing the two countries I need is safer and simpler than listing the hundred I don’t.
• Always exempt the home network, in GeoBlock and in CrowdSec. Otherwise the first person locked out is you.
• Decide what happens when a security layer fails: block everything, or let traffic through. Both are valid, but it should be a decision, not a default you never looked at.
• Test from outside. Everything looks secure from your own sofa, because your home network is on every allow list.

In short

Problem: WordPress was the last service still asking for its own password.

Solution: An OAuth2/OpenID provider in Authentik plus the OpenID Connect Generic plugin in WordPress, with every value listed below.

Tested with: WordPress 7.1, Authentik 2026.8, OpenID Connect Generic 3.11

I use Authentik as the single login for my self-hosted services. This blog should work the same way: one click on the login button, passkey, done. The normal WordPress login stays as a fallback, in case Authentik is ever down.

In the examples, Authentik runs at https://auth.example.com, the blog at https://blog.example.com, and the Authentik application slug is blog. Replace these with your own values.

How the login works

1. You click the login button on the WordPress login page.
2. WordPress sends you to Authentik, where you log in, for example with a passkey.
3. Authentik sends you back to WordPress with a one-time code.
4. WordPress exchanges the code for tokens in the background, reads your username and e-mail, and logs you in as the matching WordPress user.

1. Authentik: create the provider

In the Authentik admin interface go to Applications → Providers → Create and choose OAuth2/OpenID Provider. These are the settings I use:

For reference, the same provider created through the API:

curl -X POST https://auth.example.com/api/v3/providers/oauth2/ \
  -H "Authorization: Bearer $AUTHENTIK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Provider for Blog",
    "client_type": "confidential",
    "authorization_flow": "<uuid of default-provider-authorization-implicit-consent>",
    "invalidation_flow": "<uuid of default-provider-invalidation-flow>",
    "property_mappings": ["<openid uuid>", "<email uuid>", "<profile uuid>"],
    "signing_key": "<uuid of the signing certificate>",
    "sub_mode": "hashed_user_id",
    "include_claims_in_id_token": true,
    "grant_types": ["authorization_code", "refresh_token"],
    "redirect_uris": [{
      "matching_mode": "strict",
      "url": "https://blog.example.com/wp-admin/admin-ajax.php?action=openid-connect-authorize"
    }]
  }'

2. Authentik: create the application

Go to Applications → Applications → Create:

Then open the application, go to Policy / Group / User Bindings and bind the users or the group who may log in to WordPress. Without a binding, every Authentik user can use the application.

All endpoints are listed in the discovery document of the application. Open it once to check that it works:

curl -s https://auth.example.com/application/o/blog/.well-known/openid-configuration

3. WordPress: install the plugin

Install and activate OpenID Connect Generic (by daggerhart) from the plugin directory. The settings are under Settings → OpenID Connect Client. As soon as the plugin is active, the login page shows a button. It only works once the settings below are saved.

4. WordPress: all plugin settings

Only the JWKS URI, the End Session URL and the issuer contain the application slug. The authorize, token and userinfo endpoints are the same for every application in Authentik.

How existing users are matched

With Link Existing Users on, the plugin looks for a WordPress user whose username matches the value of the identity key, here the Authentik username (preferred_username). The first login links the two accounts, and after that the link is fixed. Use the same username in WordPress and Authentik, or log in once with the matching account. With Create user if does not exist off, nobody gets a new WordPress account just because they have an Authentik login.

Optional: keep the secret out of the database

Instead of typing the values into the settings page, you can define them in wp-config.php. The plugin then uses these values and shows the fields as read-only:

define( 'OIDC_CLIENT_ID', 'your-client-id' );
define( 'OIDC_CLIENT_SECRET', 'your-client-secret' );
define( 'OIDC_CLIENT_SCOPE', 'openid email profile' );
define( 'OIDC_ENDPOINT_LOGIN_URL', 'https://auth.example.com/application/o/authorize/' );
define( 'OIDC_ENDPOINT_USERINFO_URL', 'https://auth.example.com/application/o/userinfo/' );
define( 'OIDC_ENDPOINT_TOKEN_URL', 'https://auth.example.com/application/o/token/' );
define( 'OIDC_ENDPOINT_LOGOUT_URL', 'https://auth.example.com/application/o/blog/end-session/' );

5. Test it

Before clicking the button, test the authorize request from the command line. A working provider redirects to the Authentik login flow:

curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" \
  "https://auth.example.com/application/o/authorize/?response_type=code&scope=openid%20email%20profile&client_id=YOUR_CLIENT_ID&state=test&redirect_uri=https%3A%2F%2Fblog.example.com%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize"

# good:  302 -> https://auth.example.com/if/flow/default-authentication-flow/?...
# wrong: 302 -> https://blog.example.com/...?error=invalid_request&...

If that looks good, log out of WordPress, click the login button and log in with Authentik. You should land in the dashboard as your existing user.

Troubleshooting

What I learned

• The Authentik UI fills in defaults that the API does not.
• The server log tells you the real reason when the browser only shows a generic error.
• Keep the local WordPress login as a fallback. If the identity provider is down, you still want to reach your own site.