Authentication & Authorization Interview Questions and Answers

OAuth 2.0 is an authorization framework for delegated access. It lets a user grant a third-party application limited access to a resource without sharing the password, and the result is an access token used to call APIs. OAuth 2.0 does not define how to authenticate a user or how to convey their identity.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It adds an ID token (a JWT with standardized identity claims), a /userinfo endpoint, standardized scopes such as openid profile email, and a discovery document at /.well-known/openid-configuration.

OAuth 2.0: get an access token to call an API
OIDC:      get an ID token that tells you who logged in

Use OIDC when you need "sign in with" behavior or federated identity. Use plain OAuth 2.0 for machine-to-machine API authorization. A frequent mistake is treating an OAuth access token as proof of user identity; that is what the ID token is for.

It is the recommended flow for web, mobile and single-page applications.

1. The client generates a random code_verifier, hashes it to a code_challenge, and redirects the user to the authorization endpoint with the client id, redirect URI, scope, state and challenge.
2. The user authenticates and consents.
3. The authorization server redirects back with an authorization code and the original state.
4. The client exchanges the code at the token endpoint, sending the code_verifier.
5. The server verifies the verifier against the stored challenge and returns tokens.

GET /authorize?response_type=code&client_id=app
  &code_challenge=...&code_challenge_method=S256&state=xyz

PKCE prevents an attacker who intercepts the authorization code from redeeming it, because they lack the verifier. Always validate state for CSRF, use exact registered redirect URIs, and avoid the deprecated implicit flow that exposes tokens in the URL.

Role-Based Access Control assigns permissions to roles and roles to users, for example admin can delete any order. It is simple to reason about, easy to audit and a good default for most applications. Its weakness is role explosion and coarse decisions: rules like "editors can edit posts they own in their own department" do not fit cleanly.

Attribute-Based Access Control evaluates policies over attributes of the user, resource, action and environment, for example "allow if user.department == resource.department and time is within business hours". It is fine-grained and expressive, which suits regulated or multi-tenant systems, but policies are harder to write, test and reason about, and can be expensive to evaluate.

RBAC: if (user.roles.includes("editor")) allow
ABAC: if (user.dept === doc.dept && doc.state === "draft") allow

Many systems combine them: roles for coarse access, attributes for per-resource decisions, and relationship checks such as ownership. Evaluate centrally and log decisions for auditability.

An access token is short-lived, typically minutes, and is presented to APIs to authorize requests. If it leaks, the exposure window is small. It is usually a JWT so resource servers can verify it without a central lookup.

A refresh token is long-lived and is used only against the authorization server to obtain new access tokens, so the user does not re-authenticate constantly. It is an opaque credential, stored securely server-side or in a protected client store, and should never be sent to resource servers.

POST /token
grant_type=refresh_token&refresh_token=...&client_id=app

Best practices: keep access tokens in memory where possible, rotate refresh tokens on each use, bind them to the client, and revoke the whole chain if a used refresh token is replayed, which signals theft. Store browser tokens in HttpOnly, Secure cookies when feasible rather than localStorage, and always use TLS.

• Accepting the none algorithm or trusting the token header for algorithm selection, which enables algorithm confusion attacks. Pin the expected algorithm server-side.
• Not verifying the signature at all, or using a weak shared secret that can be brute-forced.
• Storing JWTs in localStorage, where any XSS can exfiltrate them. Prefer HttpOnly, Secure cookies for browsers.
• Long expiry with no revocation strategy; a stolen token is valid until it expires. Use short lifetimes and refresh tokens.
• Putting sensitive data in the payload and forgetting it is only base64url encoded, readable by anyone.
• Skipping validation of exp, nbf, iss or aud, so tokens from another issuer or audience are accepted.
• Using symmetric HS256 across many services, sharing the signing secret widely.

jwt.verify(token, publicKey, { algorithms: ["RS256"], issuer, audience });

Review these in security tests and prefer battle-tested libraries over hand-rolled token handling.

Cross-Site Request Forgery tricks a logged-in user's browser into sending an authenticated request to your site. Because browsers attach cookies automatically, a malicious page can trigger a state-changing request without the user's intent.

<img src="https://bank.example/transfer?to=attacker&amount=1000">

Preventions:

• Set cookies SameSite=Lax or Strict so they are not sent on cross-site requests.
• Use anti-CSRF tokens: a random value stored in the session and required in the request body or a custom header, validated server-side.
• Check the Origin or Referer header on state-changing requests.
• Require a non-simple content type such as JSON, which triggers a preflight.
• Prefer Authorization header tokens over cookies for APIs, since headers are not attached automatically.

Note that XSS defeats most CSRF defences, so prevent XSS too. Combine SameSite cookies with tokens for defence in depth.

Cross-Site Scripting lets an attacker run JavaScript in your origin. Once that happens, the script can read anything the page can read, including tokens in localStorage or sessionStorage, and can make authenticated requests as the user. It can also steal CSRF tokens by reading the DOM, defeating token-based CSRF defences.

Preventions:

• Encode output contextually and avoid innerHTML; prefer safe DOM APIs and templating that auto-escapes.
• Sanitize rich user content with an allow-list library.
• Add a strict Content Security Policy that blocks inline and third-party scripts.
• Mark session cookies HttpOnly so JavaScript cannot read them, and Secure so they only travel over TLS.
• Use short-lived access tokens and rotate them.

Content-Security-Policy: default-src 'self'; script-src 'self'

Because XSS can fully impersonate a user, treat it as an authentication threat, not just a rendering bug, and test for it in code review and automated scans.