Notifications
Clear all
Topic starter
16/08/2026 1:12 pm
TL;DR: Cookie-based sessions, JWT validation, and custom claims can be wired into a Razor Pages app to support login, profile access, and policy-based authorization, according to Descope. The identity lesson is that authentication convenience still depends on careful session handling, claim freshness, and access-policy design for customer IAM.
NHIMG editorial — based on content published by Descope: Add Authentication to ASP.NET Core With Descope
Questions worth separating out
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.
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.
Q: What breaks when application sessions outlive the identity state they represent?
A: Access decisions become detached from current identity truth.
Practitioner guidance
- 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.
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
👉 Read Descope's ASP.NET Core authentication tutorial with claims and JWTs →
ASP.NET Core auth with Descope: what changes for IAM teams?
Explore further
16/08/2026 1:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ASP.NET Core authentication with Descope and claims-based access
