ASP.NET Core authentication with Descope and claims-based access

At a glance

What this is: This is a Descope tutorial showing how to add ASP.NET Core authentication with cookies, JWT validation, and custom claims for application access control.

Why it matters: It matters because application teams often treat login integration as a developer task, but the real identity work is session governance, claim integrity, and policy enforcement.

👉 Read Descope's ASP.NET Core authentication tutorial with claims and JWTs

Context

ASP.NET Core authentication becomes a governance issue when developers rely on session cookies, JWTs, and claims to drive access decisions. The primary risk is not login convenience itself, but stale or mismanaged identity data that can outlive the session state it is supposed to represent.

For customer IAM programmes, the real question is how authentication flows translate into reliable authorisation decisions across protected routes, profile pages, and policy-based access. That is where session refresh, claim updates, and token handling move from implementation detail to identity control.

Descope’s tutorial is a practical example of that pattern: it shows how web application authentication can be assembled without custom identity plumbing, but the security outcome still depends on how accurately the app validates and refreshes the user’s session and claims.

Key questions

Q: How should teams implement claims-based authentication in ASP.NET Core without weakening access control?

A: Use claims only after defining the source of truth for each attribute, then validate sessions on the server before trusting them for access decisions. Keep authentication, token refresh, and policy evaluation separate so a signed-in browser session does not automatically grant access to every protected page.

Q: Why do custom JWT claims create governance risk if they are not refreshed?

A: Because a claim can remain technically valid after the user’s real-world status changes. If the application uses that claim for access decisions, stale department, domain, or role data can grant access that no longer matches current policy. Refresh logic and revocation rules have to match the sensitivity of the page or API.

Q: What breaks when application sessions outlive the identity state they represent?

A: Access decisions become detached from current identity truth. The user may still appear authenticated, but the authorisation layer is acting on outdated claims or expired business context. That creates a policy gap where the application trusts a session that no longer reflects the user’s real access entitlement.

Q: How do security teams decide whether cookie-based auth is acceptable for a web app?

A: Cookie-based auth is acceptable when the application can validate the session server-side, refresh identity state reliably, and enforce route-level policies for sensitive functions. If the app cannot do those things, the issue is not the cookie itself but the lack of control around how long the session remains trusted.

Technical breakdown

Claims-based identity in ASP.NET Core

ASP.NET Core represents a signed-in user through claims, a ClaimsIdentity, and a ClaimsPrincipal. Claims are individual data points such as name, email, or custom attributes, and the application reads them from the User object during requests. This model makes identity portable across controllers, Razor Pages, and middleware, but it also means the app is only as trustworthy as the claims it receives and refreshes.

Practical implication: treat claims as security inputs, not display data, and define which claims are authoritative before they reach protected routes.

Cookie sessions and JWT refresh flow

The tutorial uses cookie authentication to maintain the browser session while the backend validates session and refresh tokens with Descope. That pattern separates user experience from token validation, which is common in modern web apps, but it also creates a dependency on middleware that checks whether tokens remain valid and whether the cookie still reflects current identity state. Sliding expiration extends usability, but it can also prolong exposure if validation is weak.

Practical implication: make session refresh and token validation part of the request path for any endpoint that matters.

Custom claims and policy-based authorization

Custom JWT claims let an application express access rules that go beyond basic login status, such as allowing only users with a specific email domain to reach a page. In ASP.NET Core, authorization policies can bind those claims to route access decisions, which is useful for customer segmentation, tenant scoping, and role-like restrictions. The main design risk is assuming the claim will stay correct after issue time, especially when a user’s attributes change mid-session.

Practical implication: re-check whether the claim used for access is still valid whenever the application makes a sensitive authorization decision.

NHI Mgmt Group analysis

Claims freshness is the real control surface in claims-based ASP.NET Core auth. Once a session is reduced to a cookie and a set of claims, the application is no longer making direct identity decisions against the upstream identity system on every request. That is efficient, but it also means trust shifts to middleware, token refresh, and policy logic. Practitioners should treat claim freshness as an authorisation control, not a cosmetic identity detail.

Custom claims create governance value only when their lifecycle is explicit. The tutorial’s domain-based access example is a good illustration of how business context can be encoded into identity. The problem is that custom claims often inherit the same blind spots as static role assignments if teams never define when they expire, when they refresh, and which source of truth can override them. The implication is to govern claim lineage, not just claim content.

Session extension can widen exposure if validation is not tightly coupled to protected actions. Sliding cookie expiry is useful for usability, but it can quietly lengthen the time a compromised session remains useful. That matters most when applications blend user experience with access decisions and assume the browser session itself is evidence of continuing trust. Teams should examine whether their identity boundary ends at login or continues through the full request lifecycle.

ASP.NET Core auth is a customer IAM pattern, but the same governance logic applies across identity programmes. The same failure modes that affect user claims and session cookies also show up later in workload identity and non-human identity governance: stale trust, weak refresh logic, and unclear policy ownership. The discipline is the same even when the actor changes. Identity teams should align application auth patterns with broader IAM and lifecycle governance rather than leaving them isolated in developer tooling.

Named concept: claim drift. This tutorial highlights how a claim can remain syntactically valid while becoming operationally stale when a user’s department, domain, or access condition changes. That is claim drift: the identity still looks current to the application even though the business context has moved on. Practitioners should recognise this as a governance gap, not just a token-management issue.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why practitioners should also review OWASP Agentic AI Top 10 alongside IAM controls when identity begins to behave dynamically.

What this signals

Claim drift: ASP.NET Core applications can keep a session alive long after the identity attribute that justified access has changed. That is the same governance problem practitioners now face in broader identity programmes: a trusted assertion remains technically valid while the business condition behind it has moved. Teams should align session renewal with policy re-evaluation rather than assuming a cookie renewal equals a fresh authorisation decision.

As identity programmes expand from user login into machine identity and agentic workflows, the weakest point is often not authentication itself but the time lag between state change and access enforcement. NHI Mgmt Group research shows that 52% of companies can track and audit the data their AI agents access, which means the operational gap is already visible in adjacent identity domains. Practitioners should expect the same blind spots to surface wherever claims, tokens, or session state are allowed to drift.

For identity teams, the next step is to treat application authentication patterns as part of programme-wide governance, not isolated engineering choices. That means reviewing session duration, claim refresh, and policy ownership together, then mapping them to the same lifecycle discipline used for access reviews and entitlement changes.

For practitioners

• Map protected routes to specific claim sources Document which claims are authoritative for login, profile access, and policy checks so developers do not mix session data, JWT fields, and database attributes without a clear trust model.
• Define refresh points for sensitive authorisation decisions Require fresh token validation before pages or APIs that carry material risk, especially where a claim change should immediately alter access.
• Review sliding expiration against business risk Use a shorter session window for higher-risk applications, and make sure renewal logic cannot preserve access longer than the underlying identity should remain trusted.
• Separate authentication success from authorisation approval Keep login, token validation, and policy evaluation as distinct controls so a valid session does not automatically imply access to every protected resource.

Key takeaways

• ASP.NET Core authentication is only as strong as the freshness of the claims and sessions behind it.
• Custom claims improve authorisation precision, but they also create claim drift if teams do not refresh identity state.
• Identity governance for web apps should tie login, token validation, and policy enforcement to the same control model.

Key terms

• Claims-based identity: A way of representing a user through statements the application can read during a session, such as name, email, or custom attributes. In ASP.NET Core, those claims become the basis for access checks, which means their accuracy and freshness directly affect authorisation outcomes.
• Session refresh: The process of revalidating an authenticated session so the application continues to trust it. In web identity systems, refresh logic reduces friction, but it also extends the period during which stale or compromised identity state can remain active if controls are weak.
• Policy-based authorization: A model where access decisions are defined in a separate policy layer rather than buried inside application code. This makes permission logic easier to review, test, and govern across services, environments, and release cycles, while reducing drift between teams that would otherwise implement access rules differently.
• Discovery drift: Discovery drift is the gap that opens when live infrastructure, asset records, and ownership data move out of sync. It creates uncertainty about what exists, who owns it, and which controls apply, which in turn weakens zero trust enforcement and lifecycle governance.

What's in the full article

Descope's full tutorial covers the operational implementation this post intentionally leaves at a higher level:

• The exact Program.cs configuration for cookie authentication, session refresh, and middleware ordering in ASP.NET Core
• The login page wiring that passes session and refresh tokens from the web component into the backend
• The custom claim template setup for domain-based access decisions and policy enforcement
• The profile-page wiring that uses the authenticated identity to expose user data and edit controls

👉 Descope's full tutorial includes the middleware, login page, and custom claim configuration in working code

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.