ASP.NET Core Identity, OAuth and API Security Interview Path

The interview frame

Authentication determines who is calling. Authorization determines whether that caller may perform an action on a resource. The strongest answers name the trust boundary before naming a library or token format.

Start with five questions:

1. Which component authenticates the user?
2. Which component owns the protected resource?
3. Can the client safely hold a secret?
4. Where are tokens or sessions stored?
5. How are access, revocation and incidents observed?

ASP.NET Core mental model

Authentication handlers validate credentials and create a ClaimsPrincipal. Authorization policies then evaluate requirements. Resource-based handlers can include the target object and operation, which is essential for ownership and tenant checks.

A claim is an issuer assertion, not permission by itself. Local policy decides whether a trusted claim is sufficient for a specific action.

Threat-model categories

• Credential theft: passwords, keys, cookies or refresh tokens leak.
• Token substitution: a token for another issuer, audience or purpose is accepted.
• Replay: a valid token or authorization response is reused.
• Confused deputy: a trusted service is tricked into using its authority for the wrong caller.
• Broken object authorization: an authenticated caller accesses another user's resource.
• Information leakage: logs, errors or responses expose secrets or cross-tenant data.

Scenario

An interviewer asks whether a signed JWT makes an API secure. A complete answer is no: the API must verify signature, algorithm, issuer, audience, time and token purpose, then enforce endpoint and resource authorization. Transport security, key rotation, safe logging and incident response remain necessary.

Review checklist

• Trust boundary drawn.
• Token holder and resource server named.
• Negative paths tested.
• Authorization described separately from authentication.
• Recovery and rotation included, not postponed as operations details.