ASP.NET Core Web API interview questions covering authentication, authorization, JWT bearer tokens and API security.
Open a question for the full answer, code and interview guidance.
Authentication establishes the identity of the caller. ASP.NET Core authentication handlers inspect credentials such as bearer tokens or cookies and, when valid, create a ClaimsPrincipal representing the authenticated user.
Authorization determines whether an authenticated or anonymous caller is allowed to access a resource or perform an operation. ASP.NET Core supports role-based, claims-based, policy-based, and resource-based authorization.
Authentication verifies or establishes the caller's identity, while authorization determines what that identity is permitted to do. Authentication generally happens before authorization.
JWT stands for JSON Web Token. It is a compact token format that can carry claims and can be cryptographically signed so a server can verify that the token has not been altered.
A JWT commonly consists of three Base64URL-encoded sections separated by dots: header, payload, and signature. The header identifies metadata such as the signing algorithm, the payload contains claims, and the signature protects integrity.
Bearer authentication means possession of the access token is sufficient to present it as a credential. The client normally sends the token in the HTTP Authorization header using the Bearer scheme.
Register the JWT bearer authentication handler and configure token-validation parameters that match the trusted token issuer. The request pipeline must also execute authentication and authorization middleware before protected endpoints.
The API should validate the token's cryptographic signature and the security properties required by its trust model. Common checks include the expected issuer, intended audience, expiration/lifetime, and signing key.
Claims are statements about an identity, such as a user identifier, name, role, tenant, or permission. After authentication, ASP.NET Core exposes claims through the current ClaimsPrincipal.
Authorize requires the request to satisfy the applicable authorization policy. With no additional parameters, it normally requires an authenticated user under the configured authorization rules.
AllowAnonymous permits an endpoint to be accessed without satisfying Authorize requirements that would otherwise apply to it. It is useful for intentionally public endpoints such as login, registration, or selected public content.
Role-based authorization grants access according to roles associated with the authenticated identity, such as Admin or Manager. ASP.NET Core can enforce role requirements through Authorize attributes or policies.
Policy-based authorization defines named authorization rules composed of requirements. Policies can check claims, roles, authentication schemes, custom requirements, or combinations of conditions.
A custom authorization requirement represents an authorization condition that cannot be expressed adequately with built-in role or claim checks. An AuthorizationHandler evaluates that requirement using the current authorization context.
Resource-based authorization evaluates permission against a particular resource instance rather than only endpoint metadata. It is useful for rules such as “users may edit only records they own.”
401 indicates that valid authentication credentials are missing or were not accepted. 403 indicates that the caller is authenticated but does not have permission to perform the requested operation.
A refresh token is a credential used to obtain a new access token without requiring the user to perform the full authentication flow again. Access tokens are typically shorter-lived, while refresh tokens require stronger storage and lifecycle controls.
There is no universally correct browser storage choice because the security trade-offs depend on the architecture. JavaScript-accessible storage such as localStorage is exposed if an attacker achieves script execution through XSS.
CORS, or Cross-Origin Resource Sharing, is a browser security mechanism that controls whether frontend code from one origin may access resources from another origin. The API declares allowed origins, methods, headers, and credential behavior through CORS response headers.
AllowAnyOrigin permits browser JavaScript from any origin to make permitted cross-origin requests to the API. That may be appropriate for intentionally public APIs, but it is usually too broad for private browser applications.
HTTPS uses TLS to protect HTTP traffic against passive reading and tampering while in transit and to authenticate the server according to the certificate trust model. Credentials, bearer tokens, cookies, and application data should not travel over unprotected HTTP on untrusted networks.
Secrets should not be committed to source control or embedded in application code. Development can use mechanisms such as .NET User Secrets, while production commonly uses environment-specific secret stores, managed identity, environment variables, or platform key-management services.
Rate limiting controls how many requests a client or partition may make within defined limits. It can protect service capacity, reduce accidental overload, limit some forms of abuse, and enforce product usage policies.
Do not expose secrets, access tokens, passwords, connection strings, stack traces, or unnecessary personal information in client-facing errors. Production errors should provide safe, useful ProblemDetails responses while detailed diagnostics remain in protected server-side telemetry.
Use a trusted authentication system and validate tokens completely, including signature, issuer, audience, and lifetime. Keep authorization server-side and prefer reusable policies or resource-based checks for meaningful permissions. Apply least privilege and distinguish authentication failures from authorization failures.