# Subjects

A **subject** is any entity that can be granted permissions in Aritma IAM. Every resource-based access decision starts with identifying who or what is making the request.

There are three types of subjects:

| Type | Description | Authentication |
|  --- | --- | --- |
| **User** | A human identity linked to an Aritma ID account | Interactive login via Aritma ID or an SSO provider |
| **Client** | A machine-to-machine service identity | OAuth 2.0 `client_credentials` grant |
| **Group** | A named collection of users and clients | N/A — groups are not principals, they aggregate subjects |


## Users

A user subject represents a person. Users authenticate interactively and receive an access token after login. There are two ways a user subject can exist in your tenant:

- **Invited** — you send an invitation to an email address; the user accepts and creates or links their Aritma ID account.
- **Directly created** — if your organization has verified ownership of an email domain, you can create user subjects without the invitation step.


Users can also be provisioned by SCIM (pre-created by the IdP before their first login) or just-in-time via auto-provisioning when they sign in through an SSO provider.

## Clients

A client subject represents a non-human identity — a service, scheduled job, or integration. Clients authenticate using a client ID and secret and receive an access token directly, with no user interaction.

Clients are defined as OIDC clients with the `client_credentials` grant type. Each client has one or more secrets that can be rotated independently.

Clients are assigned policies just like users and can be members of groups.

## Groups

A group is a named collection of subjects. Groups exist to simplify access management at scale: instead of assigning a policy to each subject individually, you assign a single policy to the group and all members inherit it automatically.

Groups can contain users, clients, or other groups. When a subject is added to a group, it immediately inherits all policies assigned to that group. When it is removed, those inherited permissions are revoked instantly.

## Subject IDs

Every subject — regardless of type — is identified by a `subjectId`. This is the value you use as the `subject` field when creating policies. You can retrieve the subject ID for a user or client through the respective list or lookup endpoints.

## Related

- [User Management](/apis/platform/iam/guides/user-management) — create, invite, and manage user subjects
- [Groups](/apis/platform/iam/guides/groups) — manage group membership and group-level policies
- [OIDC Clients](/apis/platform/iam/clients/overview) — create and manage client subjects
- [Policies](/apis/platform/iam/concepts/policies) — how to grant permissions to subjects