---
title: User properties and attributes
---

## Object properties

The User object has the following properties:

- `username`: User's username.
- `email`: User's email.
- `uid`: User's unique ID. Read-only.
- `name`: User's display name.
- `is_staff`: Boolean field defining if user is staff.
- `is_active`: Boolean field defining if user is active.
- `date_joined`: Date user joined/was created. Read-only.
- `password_change_date`: Date password was last changed. Read-only.
- `path`: User's path, see [Path](#path)
- `attributes`: Dynamic attributes, see [Attributes](#attributes)
- `group_attributes()`: Merged attributes of all groups the user is member of and the user's own attributes. Ready-only.
- `ak_groups`: This is a queryset of all the user's groups.

## Examples

These are examples of how User objects can be used within Policies and Property Mappings.

### List a user's group memberships

Use the following example to list all groups that a user object is a member of:

```python
for group in user.ak_groups.all():
    yield group.name
```

### List a user's group memberships and filter based on group name

Use the following example to list groups that a user object is a member of, but filter based on group name:

```python
user.ak_groups.filter(name__startswith='test')
```

### List a user's group memberships including parent groups

Use the following example to list all groups that a user object is a member of, including parent groups:

```python
groups = [group.name for group in request.user.all_groups()]
```

:::info
For Django field lookups, see the [Django documentation](https://docs.djangoproject.com/en/stable/ref/models/querysets/#id4).
:::

## Path

Paths can be used to organize users into folders depending on which source created them or organizational structure. Paths may not start or end with a slash, but they can contain any other character as path segments. The paths are currently purely used for organization, it does not affect their permissions, group memberships, or anything else.

## Attributes

### `goauthentik.io/user/can-change-username`

Optional flag, when set to false prevents the user from changing their own username.

### `goauthentik.io/user/can-change-name`

Optional flag, when set to false prevents the user from changing their own name.

### `goauthentik.io/user/can-change-email`

Optional flag, when set to false prevents the user from changing their own email address.

### `goauthentik.io/user/token-expires`:

Optional flag, when set to false, Tokens created by the user will not expire.

Only applies when the token creation is triggered by the user with this attribute set. Additionally, the flag does not apply to superusers.

### `goauthentik.io/user/token-maximum-lifetime`:

Optional flag, when set, defines the maximum lifetime of user-created tokens. Defaults to the system setting if not set.

Only applies when `goauthentik.io/user/token-expires` set to true.

Format is string of format `days=10;hours=1;minute=3;seconds=5`.

### `goauthentik.io/user/debug`:

See [Troubleshooting access problems](../../troubleshooting/access.md), when set, the user gets a more detailed explanation of access decisions.

### `additionalHeaders`:

:::info
This field is only used by the Proxy Provider.
:::

Some applications can be configured to create new users using header information forwarded from authentik. You can forward additional header information by adding each header
underneath `additionalHeaders`:

#### Example

```yaml
additionalHeaders:
    REMOTE-USER: joe.smith
    REMOTE-EMAIL: joe@jsmith.com
    REMOTE-NAME: Joseph
```

These headers will now be passed to the application when the user logs in. Most applications will need to be configured to accept these headers. Some examples of applications that can accept additional headers from an authentik Proxy Provider are [Grafana](https://grafana.com/docs/grafana/latest/auth/auth-proxy/) and [Tandoor Recipes](https://docs.tandoor.dev/features/authentication/).
