Learn Authentik - Reputation & Threat Detection

#Introduction

In episode 18, you expanded the identity surface: legacy applications can now log in via the LDAP outpost. The more doors there are, the more important a defense system becomes. Episode 19 covers reputation and threat detection — Authentik's mechanism for recognizing IP addresses and accounts that behave suspiciously, then rejecting them before they can damage anything.

Think of it like a security officer at the building entrance. People who repeatedly fail to guess the password aren't thrown out outright, but they're recorded. The more they fail, the lower the officer's trust in them, until finally they're refused entry.

#The Reputation Concept

Authentik assigns a reputation score to two entities:

• IP reputation — the trust level for the request's originating IP address.
• User reputation — the trust level for the username used.

Scores range from 0 to 100, where a high value means trusted. These scores change dynamically following authentication behavior; they aren't static values set manually.

#How Authentik Tracks Failed Logins

Every authentication attempt passing through Authentik carries an IP address and a username. From there, the reputation engine works:

• Failed logins lower the score of the entity involved.
• Successful logins raise that score back up.

This mechanism naturally lets brute force attacks sink the attacker's own score. An attacker diligently guessing passwords actually accelerates the process of being blocked.

#Reputation Policy

The main way to use these scores is the Reputation Policy, one of Authentik's built-in policy types you first saw in episode 6. Its key settings:

• Threshold — the score threshold in the 0-100 range; a score below the threshold makes the policy return a deny result.
• Check IP — the IP address's reputation value is evaluated.
• Check username — the username's reputation value is evaluated.
• Penalize on success / failure — controls whether the score changes on successful or failed logins.

This policy is then bound to an authentication stage — usually the Identification stage or Password stage. When the score is below the threshold, the user is denied before they can proceed to the next step.

#Expression Policy on Reputation

If you need more flexible logic, you can read the score directly from the request context inside an Expression Policy. The reputation value on request.http_ip is normalized to the 0-1 range:

Expression policy — deny a poorly reputed IP

if request.http_ip and request.http_ip.reputation < 0.5:
    return False, "This IP address has a poor reputation"
return True, "IP reputation within reasonable bounds"

Test with the policy tester from episode 6 using different IPs to see the deny and allow results. Because the value is normalized, adjust this 0.5 threshold to match the test results in your environment.

#Blocking Malicious IPs Automatically

A commonly used combination:

• A reputation policy with a strict threshold on the identification stage — early blocking for recurring failing IPs and usernames.
• An expression policy like the example above for additional reputation-based rules.
• Proxy integration — IPs with a bad reputation are rejected in front of the application, even before reaching the authentication flow.

Early blocking at an early stage is cheaper than denying at the end of the flow, because it doesn't waste process cycles and doesn't give attackers more signals about your authentication structure.

#Proxy Integration

In deployments with a proxy outpost (episodes 11 to 13), reputation-based policies are also evaluated on the forward auth path. This means Authentik-protected applications won't receive requests from IPs whose reputation has dropped. This is the second layer after the network firewall: even if an IP gets past network filtering, Authentik still accounts for it.

#Monitoring Reputation

The list of reputation scores can be fetched via the API, for example from the /api/v3/core/reputation/ endpoint:

curl -s https://auth.example.com/api/v3/core/reputation/ \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" | jq '.results[] | {ip, username, score}'

In episode 22, you'll see how to use the event log to monitor failed logins and trigger automatic alerts. The combination of reputation and event matchers makes the response to attacks nearly real-time.

#Closing

Summary of episode 19:

• Reputation scores IPs and usernames in the 0-100 range; failed logins lower the score, successful logins raise it.
• A reputation policy blocks entities below the threshold when bound to an authentication stage.
• Expression policies read reputation via request.http_ip.reputation.
• Proxy integration and the reputation API create layered, monitored defenses.

In episode 20, with the security side handled, we transform the appearance: branding and theming so the Authentik login page feels like your own product. See you there!