authentik Explained: IdP, SSO, SAML, OAuth2/OIDC, Okta, and Auth0

Some README files take 30 seconds to read and still open a maze of concepts.

The goauthentik/authentik README is one of them. Right at the top, you hit this sentence:

authentik is an open-source Identity Provider (IdP) for modern SSO. It supports SAML, OAuth2/OIDC, LDAP, RADIUS, and more…

It sounds compact, but almost every word is a doorway: What is an IdP? How is SSO different from a normal login? Why do some apps use SAML while others use OAuth2/OIDC? Are Okta and Auth0 protocols, products, or both?

This post gives you the missing map. Not a certification-level deep dive, just enough context to read the README, browse the docs, or join an SSO discussion without losing the plot.

Repository: goauthentik/authentik

---

TL;DR

• IdP (Identity Provider) is the central security desk that knows who you are.
• SSO (Single Sign-On) means you log in once and enter many apps.
• SAML, OAuth2/OIDC, LDAP, and RADIUS are different “languages” apps use to talk to identity systems.
• Okta, Auth0, Microsoft Entra ID, and Ping Identity are commercial identity products.
• authentik is an open-source, self-hostable IdP that centralizes login, MFA, users, groups, policies, and an app portal.

Imagine a company with 20 internal apps: GitLab, Grafana, Nextcloud, VPN, Wi-Fi, finance dashboards, and admin tools. If every app stores users and passwords by itself, you now have 20 places to forget passwords, 20 places to disable an employee, and 20 permission models to audit.

Before we talk about what authentik fixes, look at the world without authentik. The scene below is intentionally not a clean login flow. It is the mess: every app owns its own user store, rule set, and offboarding path.

The pain is not only that users type passwords more often. That is just the visible annoyance. The deeper problem is that there is no single place to answer: who is this user, which group are they in, and should they still have access?

authentik changes the shape of the problem into one cleaner sentence: one place manages identity, many apps trust that place.

The next scene is the “cleaned-up wiring” version: apps stop owning passwords; apps speak a standard protocol; authentik checks users, groups, and policies; then authentik returns a token or assertion the app can trust.

Keep this pair of diagrams in your head. Without authentik, identity is scattered across apps. With authentik, identity becomes shared infrastructure. Every acronym below is just answering three questions: who is signing in, what may they access, and how does the app receive proof?

---

Beginner Map

To make the topic easier to absorb, do not read it like a glossary. Read it as the difference between the two diagrams above: first, every app owns identity; then, authentik centralizes identity as a shared layer.

1. Pass 1: understand why “every app handles login” becomes messy.
2. Pass 2: understand this sentence: “An IdP is where apps ask who this person is.”
3. Pass 3: separate SAML, OAuth2/OIDC, LDAP, and RADIUS by use case.
4. Pass 4: read the authentik README sentence again.

The point is role before vocabulary. Once the role is clear, the vocabulary becomes much less intimidating:

Term	Question it answers
Identity Provider	Who verifies identity?
SSO	How do we log in once and use many apps?
Protocol	Which standard language do the app and IdP speak?
Directory	Where do users and groups live?
Policy	Which rule allows or denies access?

First Practical Exercise

Pick one app you know, such as GitLab. Draw five boxes: User -> GitLab -> authentik -> Users/Groups -> GitLab. Then answer:

• Does the user type the password into GitLab or authentik?
• Does GitLab need to store the user’s password?
• If the user leaves the company, do you disable them in GitLab or authentik?

If you can answer those three questions, the rest of the article becomes lighter: we are mostly putting precise names on the arrows in that tiny diagram.

---

Part 1: Foundations - What are IdP and SSO?

Look back at the with authentik scene. The most important node is not GitLab, Grafana, or VPN. It is authentik IdP, because that is the shared place apps ask: “who is this user, and should they get in?”

IdP: the central security desk, but for software

An Identity Provider (IdP) answers one question:

“Is this person really who they claim to be?”

In a company building, the IdP is the central security desk:

• An employee shows a badge or fingerprint.
• Security checks the employee record.
• If valid, security says: “Yes, this is Hoang from Engineering.”
• Other departments do not need to verify the ID from scratch.

In software, the same idea happens faster and more formally:

• The user does not necessarily type a password into every app.
• The app sends the user to the IdP.
• The IdP authenticates with password, passkey, TOTP, WebAuthn, email, or MFA.
• The IdP sends proof back to the app.
• The app trusts that proof and lets the user in.

SSO: one verification, many doors

Single Sign-On (SSO) is the experience where you log in once and then open other apps without typing the password again.

Example:

1. You open GitLab.
2. GitLab redirects you to authentik.
3. You log in at authentik.
4. GitLab lets you in.
5. You open Grafana.
6. Grafana also asks authentik.
7. authentik sees that your session is still valid, so Grafana lets you in too.

The key point: SSO does not mean trading security for convenience. It centralizes security so MFA, user deactivation, audit logs, and access policies behave consistently. Convenience is the visible benefit; centralized control is the real one.

---

Part 2: The Investigation - What does authentik do during one login?

Now zoom into the middle of the with authentik scene. A login looks simple from the outside, but inside it is several small pieces cooperating:

• User: an account.
• Group: a group such as engineering, finance, or admin.
• Application: an app shown on the user dashboard, such as GitLab or Grafana.
• Provider: the technical configuration that lets an app talk to authentik with SAML, OAuth2/OIDC, proxy, LDAP, and other protocols.
• Flow: a sequence of login steps, such as username, password, MFA, and login.
• Stage: one small step inside a Flow.
• Policy: a reusable check, such as “only engineering can open Grafana” or “unknown IP requires MFA.”

When those pieces come together, a typical login looks like this:

1. The user opens an app.
2. The app says: “I do not handle login myself; go ask authentik.”
3. authentik runs a Flow: identify the user, verify the password, ask for MFA if needed.
4. authentik evaluates Policy: is this user in a group allowed to access this app?
5. If allowed, authentik returns a token or assertion.
6. The app reads that proof and creates its own app session.

From the user’s point of view, it is one login screen. From the system’s point of view, it is a small assembly line: verify identity, check access, then issue proof the application can trust.

---

Part 3: The Diagnosis - How are SAML, OAuth2/OIDC, LDAP, and RADIUS different?

This is the part where people usually get lost, because protocol names sound interchangeable. Do not start by asking for the textbook definition. Start with the practical question: what kind of conversation does this app need?

Term	Quick mental model	Common context
SAML	Enterprise SSO standard, often using XML assertions.	“This employee is Hoang from Engineering; let him into Salesforce.”
OAuth2	Authorization standard: app A may do action X for a user.	“Let the calendar app read my calendar, but not my email.”
OIDC	Login layer on top of OAuth2 that returns identity information.	Modern “Log in with Google.”
LDAP	Older but still common way to query users and groups.	NAS, Jenkins, or VPN asks: “which group is this user in?”
RADIUS	Common in network access.	Wi-Fi or VPN asks a server: “can this account enter the network?”

OAuth2 is not automatically login

Original OAuth2 is about authorization: granting an app permission to do something. OIDC adds the identity layer that makes it a cleaner login standard.

If we compress everything into the language of keys and signed letters:

• OAuth2: “Which key may this app hold?”
• OIDC: “Who is holding this key?”
• SAML: “Here is a signed identity letter.”
• LDAP: “Please search the user/group directory.”
• RADIUS: “Should this network device allow this user?”

---

Part 4: The Resolution - authentik vs. Okta, Auth0, Entra ID, and Ping Identity

Once protocols make sense, the vendor names become much easier. Okta, Auth0, Microsoft Entra ID, and Ping Identity are not standards like SAML or OIDC. They are IdP or identity platform products.

A practical comparison:

Product	Quick way to think about it
Okta	Popular enterprise SaaS IdP for larger organizations.
Auth0	Developer-friendly login platform, especially strong for customer identity.
Microsoft Entra ID	Identity tightly integrated with Microsoft 365/Azure; formerly familiar as Azure AD.
Ping Identity	Long-running identity platform for complex enterprise environments.
authentik	Open-source, self-hostable IdP for homelabs, startups, internal platforms, and teams that want infrastructure control.

To compare fairly, do not read the scene below as “authentik beats everything.” Managed SaaS IdPs are excellent at operations, enterprise ecosystems, support, and compliance. authentik’s strength is on a different axis: control, self-hosting, inspectability, custom flows/policies, and bridging old and new app protocols.

What makes authentik interesting is that it brings many enterprise-style identity building blocks into a self-hostable system you can actually inspect and learn from:

• An app dashboard for users.
• An admin UI for users, groups, providers, flows, events, and applications.
• Flows and stages to customize the login process.
• Policies to attach rules to flows, apps, and sources.
• Multiple protocols for old and new apps.
• Self-hosting via Docker Compose for labs or Kubernetes for larger setups.

But that freedom comes with real operational responsibility:

• You must back up the database.
• You must protect secrets and TLS.
• You must update versions.
• You must design recovery for IdP downtime, because if the IdP is down, many apps may not be able to log users in.

When should you use authentik?

Consider it if you:

• Have multiple internal apps and want one login gateway.
• Want to understand identity management through real operations, not only definitions.
• Want to self-host, control data, or avoid depending entirely on SaaS.
• Need to connect both old and new apps with multiple protocols.

On the other hand, if you have one small app, one simple user table, and no need for centralized SSO, MFA, or audit logs, authentik may be too early. A good tool is not always the tool you need today.

---

Final Take

By the end, the maze collapses into one sentence:

authentik is the identity checkpoint between users and applications.

It is not just a nicer login page. It is the coordination layer where you centralize:

• who the user is,
• which groups the user belongs to,
• which apps the user may access,
• which steps login requires,
• which policies apply,
• which protocol each app uses to receive proof.

When the README says “open-source Identity Provider for modern SSO,” translate it in your head as:

“An open-source system where apps can ask one shared place: who is this user, are they allowed in, and which standard should carry the login proof?”

Seen this way, the README stops being a wall of acronyms. It becomes a surprisingly accurate description: authentik turns identity management from scattered app-by-app decisions into one control point you can understand, configure, and operate.