Claim

A security token is a digitally signed data object, such as a JSON Web Token (JWT) or SAML assertion, that encapsulates and transmits claims. It serves as the vehicle for claims, proving authentication and conveying authorization grants in a stateless manner between systems.

• Structure: Typically contains a header (algorithm), payload (claims), and signature.
• Function: Enables single sign-on (SSO) and API authorization by allowing a service to trust the token's issuer (the Identity Provider).
• Verification: The receiving service validates the token's signature and checks the claims against its authorization policy.

An Identity Provider (IdP) is the authoritative system that creates, manages, and asserts claims about a subject (user or service). It is the source of truth for identity attributes and is responsible for the initial authentication event.

• Core Function: Authenticates a principal and issues security tokens containing verified claims.
• Examples: Okta, Azure Active Directory, Auth0.
• Trust Relationship: Service Providers (applications) trust the IdP's signatures and the claims it asserts. The IdP does not make access decisions for the application; it provides the data (claims) for the application's Policy Decision Point to use.

The Policy Decision Point (PDP) is the authorization engine that evaluates an access request—including the subject's claims, the requested action, and the target resource—against a set of policies to render an allow or deny decision.

• Input: Consumes claims from a security token, resource context, and environmental attributes.
• Logic: Applies policy rules (e.g., "Allow if claim role equals admin").
• Output: Sends a permit/deny decision to the Policy Enforcement Point (PEP). Tools like Open Policy Agent (OPA) are specialized PDPs that decouple policy logic from application code.

Attribute-Based Access Control (ABAC) is an authorization model that uses claims (called attributes) as the primary basis for access decisions. A claim is a type of attribute about the subject.

• Evaluation: Grants or denies access based on attributes of the user (claims), the resource (e.g., sensitivity tag), the action, and the environment (e.g., time, location).
• Policy Language: Uses boolean logic (e.g., PERMIT IF user.department == resource.owner AND time.now < 17:00).
• Relationship to Claims: ABAC policies are the rules that evaluate the claims presented in a security token. It enables fine-grained, context-aware authorization beyond simple role checks.

OAuth 2.0 scopes are a specialized type of claim that limit an access token's authority. They are strings (e.g., read:contacts, user:email) requested by a client application and granted by the resource owner, defining the breadth of access the token provides.

• Purpose: Implement the principle of least privilege for API access. A token with scope read cannot perform write operations.
• As a Claim: Scopes are often included as a claim within a JWT (e.g., "scope": "read write").
• User Consent: During authorization, users see the requested scopes and consent to them, which is a key privacy and security control.

Security Assertion Markup Language (SAML) is an XML-based open standard that defines a framework for exchanging authentication and authorization data, specifically SAML assertions, which are containers for claims.

• SAML Assertion: An XML document issued by an IdP that contains statements (claims) about a subject. The three types of statements are Authentication, Attribute, and Authorization Decision.
• Use Case: Primarily used for enterprise web single sign-on (SSO). A user authenticates with a corporate IdP, which sends a SAML assertion to a cloud service (like Salesforce) to grant access.
• Comparison to JWT: SAML is XML-based and often used in browser-based flows, while JWTs (JSON-based) are common for APIs and are more compact.