What is the difference between authentication claims and authorization claims in SharePoint federation?

Authentication claims prove that the user has been authenticated by the trusted identity provider, while authorization claims carry the role or identity attributes SharePoint uses to decide access. In this pattern, ADFS issues the token, SharePoint validates it, then SharePoint applies its own claims and permission checks before granting access to the web application.

How Authentication Claims and Authorization Claims Differ in SharePoint Federation

In SharePoint federation, the two claim types answer different questions. Authentication claims establish who was successfully signed in by the trusted identity provider, while authorization claims describe what SharePoint should do with that identity once the token is accepted. The practical difference is that one proves authentication, and the other drives access decisions inside SharePoint.

That distinction matters because the token can be valid even when the user still should not receive a given permission set. SharePoint federation is therefore not just about trusting a sign-in, it is about separating proof of identity from the attributes and rules used for access enforcement.

What SharePoint Uses Each Claim Type For

Authentication claims are the federation layer’s evidence that the user was authenticated upstream, typically by ADFS or another trusted identity provider. They let SharePoint trust the sign-in event and establish a session context without re-authenticating the user itself. In other words, these claims answer the question, “Has this user already proven who they are?”

Authorization claims answer a different question: “What access should this user get here?” These claims may carry group membership, role, or other identity attributes that SharePoint evaluates when it applies its own permission model. A user can be successfully authenticated but still denied because the authorization claims do not match the site, list, or item permissions configured in SharePoint.

That separation is the core design benefit of claims-based federation. It lets the identity provider vouch for the user’s identity, while SharePoint retains the final say over local authorization. For practitioners, the important point is that authentication claims are necessary for trust, but they are not sufficient for access.

Why the Boundary Matters in Federation Design

Claims confusion usually appears when teams assume that a valid federated token should automatically grant the user whatever the identity provider says. In SharePoint, that is not how the model works. The federation token is only the input; SharePoint still maps incoming claims to its own rules before access is granted. That is why the same user may be authenticated successfully yet receive different results across web applications, zones, or site collections.

The distinction also helps with troubleshooting. If sign-in succeeds but access fails, the issue is often not authentication at all, but claim mapping, rule configuration, or permission assignment. If the user never reaches a trusted authenticated state, the problem is upstream, in token issuance, trust configuration, or the federation handshake. Treating those as separate failure domains speeds up diagnosis and avoids overcorrecting the wrong layer.

For a concise technical reference on token layering and sign-in semantics, see the OpenID Connect Core 1.0 specification. For identity assurance and authentication strength concepts that often sit beneath federation decisions, the NIST SP 800-63 Digital Identity Guidelines provide useful context.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	SharePoint federation depends on proving user identity before access decisions.
	AC-3 — Access Enforcement	SharePoint applies authorization claims through its own access enforcement rules.
	IA-5 — Authenticator Management	Federated sign-in depends on managed authentication material and trust issuance.
Recommendation — Enforce IA-2 to validate user authentication before evaluating SharePoint access. Use AC-3 to enforce SharePoint permissions after claims are accepted. Apply IA-5 to protect and rotate authenticators that support federation trust.
ISO/IEC 27001:2022	A.5.15 — Access control	Federated claims ultimately support access control decisions in SharePoint.
	A.5.16 — Identity management	Federation relies on trustworthy identity handling across systems.
Recommendation — Apply A.5.15 to define how claims map to permitted access. Use A.5.16 to govern identity assertions and their lifecycle.

Practitioner Guidance

What to verify: Confirm that your trusted identity provider is only issuing the authentication signal you intend, and that SharePoint is separately mapping authorization claims to the correct local permissions. A token that proves identity should not be assumed to confer site access.

Decision rule: If the user is authenticated but access is wrong, inspect claim mapping and SharePoint permissions first; if the user cannot authenticate at all, inspect federation trust, token issuance, and the identity provider. That split keeps investigation aligned to the actual failure point.

What good looks like: Authentication claims are stable and minimal, authorization claims are explicit and least-privilege, and SharePoint’s permission checks remain the final gate before access. The result is predictable access behavior with fewer surprises when users move between applications or audiences.

Practitioner takeaway: In SharePoint federation, authentication establishes trust in the user, but authorization determines what that trusted user may actually do. Keep those responsibilities separate, or you will misdiagnose access failures and overgrant permissions.