| 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). 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. |
About
/Glossary
Last updated