Learn Authentik - Users, Groups & Attributes

#Introduction

Now that you understand flows & stages from episode 4 — and how Authentik assembles authentication blocks — it's time to manage the main ingredient: users and groups. Without users, flows have no one to authenticate; without groups, policies have no way to manage access centrally. Make sure your stack is up (docker compose ps) before practicing.

This episode covers identity management: creating users and groups, user properties and status, service accounts and impersonation, custom attributes usable by policies and property mappings, user sources from internal to LDAP and social login, and bulk import via the API.

#User Management

#Creating Users

In the admin interface: Directory → Users → Create User. The minimum required fields: username, name, and email. Once the user is created, you can set a password via the user actions.

#User Properties

The core properties to understand:

• username — the unique identifier used for login.
• name — the display name.
• email — the identity and communication channel (password reset, notifications).
• is_active — the active/inactive status. Inactive users can't log in.
• is_superuser — full admin rights; only grant it to those who truly need it.
• attributes — a free-form JSON data column (covered in the Attributes section).

#Active and Inactive Status

Deactivating a user (the is_active toggle) is the fast way to cut off access without deleting data. This is safer than deletion: the account remains for auditing but can't be used. To cut access immediately, deactivate; delete only if the account really must be discarded along with its attribute data.

#Password Management

Admins can set a user's password via the UI, and users can change their own via the user interface or the recovery flow. Never share passwords over insecure channels; for teams, point them to the recovery flow.

#Service Accounts

Authentik has service accounts — accounts without passwords used for automation (API, scripts, machine-to-machine integrations). Create them via Directory → Users → Service Accounts. Service accounts use tokens, not passwords, and are well suited for integrations like outposts and CI/CD.

#User Impersonation

Admins can impersonate a user — "log in as" that user without knowing their password. This is very useful for debugging issues that only specific users experience. Use it carefully: all impersonation actions are recorded in the event log.

#Groups

Groups are the way to manage access centrally: one group, many members, and policies only need to reference the group name.

• Creating a group — Directory → Groups → Create Group, give it a name (for example engineering).
• Membership — add users one by one or in bulk. This membership is what policies read (for example "only members of the engineering group").
• Group hierarchy — groups can have a parent; child group membership is considered in certain access logic. Start simple: flat groups first, then hierarchies.
• Group attributes — groups also have a JSON attributes column; used for context data (for example department code, access level).
• Default groups — the installation creates two built-in groups: authentik Admins (full) and authentik Users (all users automatically become members).

#Attributes & Custom Fields

Attributes are a free-form JSON column on both users and groups — a sort of "custom fields" you can fill with anything. Real-world usage examples:

• Storing department, employee_id, or location on a user.
• Storing sla_tier on a group.
• Reading them in an expression policy to decide access.

Expression policy reading a user attribute

if request.user.attributes.get("department") == "engineering":
    return True
return False

Attributes can also be passed to applications via property mappings (covered in episode 9) — for example, injecting department into an OIDC token claim.

#User Sources

Authentik users aren't always created manually. There are several identity sources:

• Internal — users created directly in Authentik.
• LDAP / Active Directory — users synchronized from an existing directory (episode 17).
• OAuth sources — login via Google, GitHub, Discord, and others; users are auto-created on first login (episode 16).
• SAML sources — federation from an external IdP.
• SCIM provisioning — automatic user provisioning from an HR system or another IdP.

Sources fill users into Authentik; policies and flows work with them just like internal users.

#Bulk Operations and Mass Import

To create many users at once, don't click one by one — use the API. Authentik provides a complete REST API with Swagger documentation at auth.example.com/api/v3/docs/. The basic pattern: create a token in the admin interface, then send requests to the user endpoint.

curl -X POST \
  -H "Authorization: Bearer <API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"username": "budi", "name": "Budi Santoso",
       "email": "budi@example.com"}' \
  https://auth.example.com/api/v3/core/users/

A common mass import strategy: create a CSV file with username, name, email, and group columns; then loop through the CSV rows with a script (Python, Bash, or anything else) that calls the API. We'll dissect API details and automation thoroughly in episode 21.

#Closing

In this episode 5, you understood identity management in Authentik: creating users with properties like username, name, email, the is_active status, and is_superuser; using service accounts for automation and impersonation for debugging; managing groups with hierarchies and the built-in authentik Admins and authentik Users groups; leveraging JSON attributes for custom data read by policies; getting to know user sources from LDAP to social login; and mass import via the API.

Key takeaways:

• Deactivate, don't delete, when cutting off access — auditing stays alive.
• Manage access group-based, not per-user.
• Attributes are the bridge between business data and access decisions.
• API + CSV for mass import; never commit tokens.

In episode 6, we dive into the heart of authorization: Policies — conditional logic with Python expression policies, a policy engine with AND/OR, and real use cases like group-based access, IP restrictions, and MFA enforcement. See you in episode 6!