Category: Authorization Concepts

Subject

Also known as: Principal

Simply put

In identity and access management, a subject is the entity that is trying to access something, such as a person, an application, or a device. It is the 'who' or 'what' that a system identifies, authenticates, and then decides whether to allow into a resource. The term draws on the general meaning of something placed under authority or control, applied here to entities governed by access policies.

Formal definition

A subject is the active entity (typically a user, service account, workload, or device) whose identity is asserted and evaluated during an access flow. In most access control and policy evaluation contexts, the subject is the entity to which identification, authentication, and authorization steps are applied in sequence: the subject is first identified, then authenticated to verify the asserted identity, and then authorized against applicable policy to determine permitted actions. The subject is frequently represented by attributes and claims that a policy decision point (PDP) evaluates in models such as RBAC, ABAC, PBAC, or ReBAC. The precise definition of 'subject' varies by standard, profile, and vendor deployment; some specifications use 'principal' as a closely related or synonymous term, and the exact semantics should be confirmed against the governing specification in a given context. Note that the general-language sense of 'subject' as a topic of discussion or as a grammatical sentence component is out of scope for this IAM usage.

Why it matters

The subject is the anchor of nearly every access decision an identity system makes. Before a system can enforce any policy, it must establish which entity is making the request, a person, a service account, a workload, or a device, and represent that entity consistently across identification, authentication, and authorization steps. If the subject is misidentified or its asserted identity is not properly verified, every downstream authorization decision inherits that flaw. Getting the subject right is therefore a prerequisite for meaningful access control rather than an afterthought.

The concept also matters because subjects are increasingly non-human. Modern deployments must treat service accounts, automated workloads, and devices as first-class subjects, each with its own identity, attributes, and lifecycle. Systems that model subjects only as human users tend to accumulate poorly governed machine identities, which become a common source of over-privileged and unmonitored access. Treating the subject as a general active entity, not just an interactive user, helps architects apply consistent authentication and policy evaluation across the full range of principals that request resources.

Because the precise semantics of 'subject' vary by standard, profile, and vendor, imprecision here creates real interoperability and audit risk. Some specifications use 'principal' as a closely related or synonymous term, and the attributes and claims that describe a subject may differ in meaning across systems. When a subject's identity flows between an identity provider, a token, and a policy decision point, teams should confirm the exact meaning of 'subject' against the governing specification rather than assuming a shared definition.

Who it's relevant to

Security Architects

Architects define how subjects are represented across identification, authentication, and authorization, including how human users, service accounts, workloads, and devices are each modeled as active entities. Consistent subject modeling across systems is foundational to designing coherent access control and avoiding gaps where non-human subjects escape proper governance.

IAM Engineers

Engineers implement the flow that carries a subject from identification through authentication and into policy evaluation, mapping the subject to the attributes and claims a PDP consumes. Because 'subject' and the related term 'principal' can differ in meaning across standards and vendors, engineers must confirm the exact semantics against the governing specification when integrating systems.

Identity Governance Leads

Governance leads oversee the lifecycle of subjects, including human and non-human identities such as service accounts and workloads, ensuring each has appropriate attributes, ownership, and review. Treating machine subjects as first-class governed entities helps prevent the accumulation of poorly managed and over-privileged access.

Compliance Officers and Auditors

Auditors trace how a subject's identity is asserted, verified, and evaluated against policy to confirm that access decisions are attributable to a correctly identified entity. Because the definition of 'subject' varies by standard and deployment, compliance reviews should reference the applicable specification when assessing whether subject identity is handled consistently.

Inside Subject

Subject identifier

The value that uniquely denotes the principal within a given context, such as the 'sub' claim in an OpenID Connect ID token or the NameID element in a SAML 2.0 assertion. The identifier is scoped to an issuer and is not guaranteed to be globally unique or portable across systems.

Principal

The entity a subject represents, which may be a human user, a service account, a device, or a workload. The subject is the representation of that principal that a system reasons about during identification, authentication, and authorization.

Subject in the 'sub' claim (OIDC)

In OpenID Connect Core, the 'sub' claim carried in the ID token identifies the authenticated end user at the issuer. It is typically stable and, depending on configuration, may be pairwise (per relying party) or public across relying parties.

Subject in SAML 2.0

In a SAML 2.0 assertion, the Subject element (commonly containing a NameID) identifies the entity the assertion is about, and is used by the relying party to establish who the authenticated principal is for web SSO.

Subject in access control decisions

During authorization, the subject is the actor whose attributes, roles, or relationships are evaluated. In ABAC the subject contributes attributes, in RBAC it is associated with roles, and in ReBAC it participates in relationships that a policy decision point evaluates.

Subject attributes

Claims or properties associated with the subject, sourced from directories (for example LDAP) or a policy information point at runtime, that describe the principal for authorization purposes without redefining who the subject is.

Common questions

Answers to the questions practitioners most commonly ask about Subject.

Is the subject the same thing as the user?

Not necessarily. A subject is the principal that a claim or assertion is about, and while it is often a human user, it can also be a service account, workload, device, or other non-human identity. Treating subject and user as synonyms is imprecise because many subjects in modern deployments are not people. The subject is defined by the entity an authenticated identity represents, not by whether that entity is human.

Does the subject identifier tell me what the subject is allowed to do?

No. The subject identifies who or what a principal is, which is an identification and authentication concern, whereas what the subject may do is an authorization decision made separately. A subject identifier by itself conveys identity, not entitlements. Permissions are derived from roles, attributes, policies, or relationships evaluated at authorization time, depending on the access control model in use, and should not be inferred from the subject value alone.

Which claim carries the subject in an OpenID Connect ID token?

In OIDC Core, the subject is conveyed in the 'sub' claim of the ID token, which identifies the authenticated end user. The 'sub' value is typically intended to be a stable, unique identifier for the subject within the scope of a given issuer, though its exact format and uniqueness guarantees depend on the identity provider's configuration.

Should I use the 'sub' claim as the primary key for a user account in my application?

In most deployments the combination of issuer ('iss') and subject ('sub') is treated as the reliable key for correlating an account, since a 'sub' value is typically only guaranteed unique within its issuer. Depending on provider configuration, a raw 'sub' alone may not be globally unique, so relying on it without also binding to the issuer can cause collisions when multiple identity sources are involved.

How does the subject in a SAML 2.0 assertion differ from the subject in a JWT?

In SAML 2.0 the subject is expressed in the <Subject> element, often with a <NameID> and associated format, whereas in a JWT the subject is carried in the 'sub' claim. Both identify the principal the assertion or token is about, but the encoding, supported identifier formats, and confirmation mechanisms differ by standard. The semantics of stability and scope of the identifier depend on the issuing system's configuration in each case.

How should a subject identifier be handled when provisioning accounts across systems?

When provisioning across systems, for example via SCIM, it is common to maintain a mapping between an authoritative subject identifier and the local identifiers used by each target system, since a subject may be represented differently in a directory, an application, and a token. Preserving a consistent correlation to the subject supports lifecycle operations such as updates and deprovisioning, but the specific identifier used and its mutability depend on the source of authority and the systems involved.

Common misconceptions

The subject identifier is a globally unique, portable value that means the same thing across all systems.

A subject identifier is typically scoped to its issuing authority. In OpenID Connect the 'sub' value is meaningful within the context of the issuer, and may be pairwise per relying party depending on configuration, so it should not be assumed unique or consistent across different issuers or applications.

Establishing the subject is the same as authorizing it.

Identifying and authenticating the subject (verifying who the principal is) is a distinct step from authorization (determining what the principal may do). The subject provides the actor input to an authorization decision but does not by itself grant any access.

A subject always represents a human user.

A subject can represent any principal, including service accounts, devices, or workloads. Treating every subject as a person can lead to incorrect assumptions in provisioning, governance, and runtime enforcement for non-human identities.

Best practices

Treat subject identifiers as issuer-scoped, and record which issuer or authority a subject value originates from rather than assuming cross-system portability.

Keep identification of the subject separate from authorization logic, passing subject attributes to the policy decision point rather than embedding access decisions into the identity itself.

Choose pairwise versus public subject identifiers deliberately in OpenID Connect deployments based on privacy and correlation requirements, and document the choice per relying party.

Source subject attributes for authorization from an authoritative directory or policy information point at evaluation time, distinguishing stable identity data from dynamic attributes.

Account for non-human subjects such as service accounts and workloads when designing subject handling, since their lifecycle and attributes differ from human users.

Avoid overloading the subject identifier with additional meaning or data, keeping it as a stable reference and carrying descriptive information in separate claims or attributes.