# Glossary

| Term | Description |
|  --- | --- |
| **Subject** | Anything that can be granted permissions in Aritma IAM. Subjects can be users, clients, or groups. |
| **User** | A human identity linked to an Aritma ID account. Users can log in interactively via Aritma ID or via an SSO provider. |
| **Client** | An OIDC service client used for machine-to-machine API access. Clients authenticate using the `client_credentials` grant and are assigned policies just like users. |
| **Group** | A named collection of subjects. Policies assigned to a group apply to all members automatically. |
| **Policy** | The binding that grants a subject permission to perform an action on a scope. Every resource-based access decision resolves to one or more policies. |
| **Action** | A string that represents what a subject is allowed to do, e.g. `banking.manage` or `banking.ais.read`. Actions form a hierarchy — granting a parent action implicitly grants all child actions beneath it. |
| **Scope** | A URI that identifies the resource a policy applies to, e.g. `/subscriptions/123/resource-groups/...`. The same subject can have different permissions on different scopes. Permissions over a scope is inherited by subscopes. |
| **Tenant** | Your organization's isolated environment on the Aritma platform. All IAM resources (users, clients, groups, policies) are scoped to a tenant. |
| **Tenant Role** | An OIDC role that represents a subject's standing within a tenant, e.g. `TenantAdmin`. Tenant roles are returned as claims in access tokens and are used for coarse-grained authorization. |
| **SSO** | Single Sign-On. Lets users authenticate via an external identity provider (IdP) instead of managing separate Aritma ID credentials. |
| **Identity Provider (IdP)** | An external system that authenticates users, such as Microsoft Entra ID, Google, or a custom OIDC provider. |
| **OIDC** | OpenID Connect. An authentication layer built on top of OAuth 2.0. Used by Aritma IAM for both SSO federation and client authentication. |
| **OAuth 2.0** | An authorization framework. Clients obtain access tokens by presenting credentials to a token endpoint and then include the token in API requests. |
| **SCIM** | System for Cross-domain Identity Management ([RFC 7644](https://www.rfc-editor.org/rfc/rfc7644)). An open standard that allows an identity provider to automatically provision and deprovision users and groups in Aritma. |
| **SCIM Token** | A bearer token issued by Aritma IAM and configured in your identity provider to authorize SCIM provisioning requests. |
| **Auto-provisioning** | When enabled on an SSO provider, Aritma automatically creates a user subject the first time they log in — no pre-invitation required. |
| **Delegation** | When enabled on an SSO provider, tokens issued by that IdP can be used to call Aritma APIs directly, without exchanging them for an Aritma token. |
| **Claim** | A key-value pair included in an OIDC access or identity token. Claims convey information about the authenticated subject (name, email, roles, permissions) to consuming applications. |
| **Domain Verification** | Proving ownership of an email domain by publishing a DNS TXT record. Required before you can create users directly (without invitations) for email addresses on that domain. |
| **client_credentials** | An OAuth 2.0 grant type used by machine-to-machine clients. The client exchanges a client ID and secret for an access token directly, with no user interaction. |
| **authorization_code** | An OAuth 2.0 grant type used by user-facing applications. The user is redirected to the authorization endpoint, authenticates, and an authorization code is exchanged for tokens. |
| **PKCE** | Proof Key for Code Exchange. An extension to the authorization code flow that prevents authorization code interception attacks. Required for public clients that cannot store a client secret. |