ASP.NET Core interview questions covering authentication, authorization & security.
Open a question for the full answer, code and interview guidance.
Authentication is the process of determining who a user or client is. ASP.NET Core authentication handlers examine credentials such as an authentication cookie, bearer token, certificate, or external-provider response and build a ClaimsPrincipal when authentication succeeds.
Authorization determines whether an authenticated or anonymous user is allowed to perform an operation or access a resource. ASP.NET Core supports role-based, claims-based, policy-based, and resource-based authorization.
Authentication answers “Who are you?” while authorization answers “What are you allowed to do?” Authentication establishes an identity; authorization evaluates access rules for that identity.
An authentication scheme is a named configuration that identifies an authentication handler and its options. Applications can have multiple schemes, such as cookies for the web UI and JWT bearer authentication for APIs.
Cookie authentication stores an encrypted authentication ticket in a browser cookie after sign-in. On later requests, the cookie handler validates the ticket and reconstructs the user's ClaimsPrincipal.
ClaimsPrincipal represents the current security principal and can contain one or more ClaimsIdentity objects. Each identity contains claims describing the subject, such as name, user identifier, role, permission, or other attributes.
A claim is a name/value statement about an identity. Examples include a user ID, email address, department, role, subscription level, or application-specific permission.
Role-based authorization grants access according to roles assigned to the current user, such as Admin, Editor, or Manager. ASP.NET Core can enforce roles with the Authorize attribute or authorization policies.
Claims-based authorization evaluates claims contained in the user's ClaimsPrincipal. Instead of asking only whether a user belongs to a role, a policy can require a particular claim or claim value.
Policy-based authorization defines named policies made up of one or more requirements. A policy can require authentication, roles, claims, assertions, or custom authorization requirements.
A custom authorization requirement represents an access condition that cannot be expressed cleanly with built-in role or claim requirements. A handler evaluates the requirement against the current authorization context and calls Succeed when the condition is met.
Resource-based authorization evaluates access using both the current user and the specific resource being accessed. It is useful when the decision depends on data loaded at runtime, such as whether the current user owns a document or may edit a particular order.
AllowAnonymous marks an action, controller, page, or endpoint as accessible without satisfying normal authorization requirements applied at a broader level.
ASP.NET Core Identity is a membership system for managing application users. It provides services for user creation, password hashing, sign-in, roles, claims, tokens, email confirmation, password reset, lockout, and related account features.
UserManager<TUser> provides user-management operations such as creating users, validating/changing passwords, managing roles and claims, generating tokens, and confirming accounts.
ASP.NET Core Identity stores password hashes rather than plaintext passwords. Its password hasher uses a salted, deliberately expensive password-based hashing approach and stores metadata needed to verify and, when appropriate, upgrade hashes.
JWT bearer authentication is commonly used by APIs to authenticate requests carrying a bearer token in the Authorization header. A JWT can contain claims and is cryptographically signed so the API can validate its integrity and issuer information.
Despite its historical name, HTTP 401 generally means the request is not successfully authenticated for the protected resource. The server can issue an authentication challenge telling the client how to authenticate.
Cross-Site Request Forgery (CSRF) occurs when a malicious site causes a victim's browser to send an unwanted state-changing request to another site where the browser automatically supplies credentials such as authentication cookies.
Cross-Site Scripting (XSS) occurs when untrusted data is rendered as executable browser content, typically JavaScript or malicious HTML. Razor normally HTML-encodes output, which is an important default defense.
SQL injection occurs when untrusted input is combined with SQL text in a way that changes the intended SQL command. The primary defense is parameterization.
Secrets such as production passwords, API keys, signing credentials, and connection-string passwords should not be committed to source control or embedded in application code.
Authentication cookies should normally be HttpOnly so client-side scripts cannot read them, Secure so they are sent over HTTPS, and configured with an appropriate SameSite policy for the application's authentication and cross-site requirements.
Least privilege means users, application identities, database accounts, services, and infrastructure components receive only the permissions required to perform their intended tasks.
Use HTTPS, secure authentication mechanisms, explicit authorization policies, least privilege, anti-forgery protection for applicable browser requests, and parameterized database access. Treat all external input as untrusted and rely on context-appropriate output encoding.