Authentication and Authorization Interview Questions: OAuth, OIDC, JWT, and Sessions

The JWT is valid. Its signature checks out. The user is authenticated. Yet the API just returned another tenant's invoice. What failed?

This is where authentication and authorization interview questions stop being vocabulary tests. A strong engineer separates identity from permission, validates every token in its intended context, and still performs an object-level authorization decision for the requested action.

Start with PracHub's real signup and login system question, then practice JWT validation in a real API task. Use the broader interview question bank with written solutions to connect these security decisions to backend and system design rounds.

Quick Answer: OAuth, OIDC, JWT, and Sessions Are Not Alternatives

These terms solve different parts of the problem. A senior answer starts by naming the exact job each mechanism performs instead of asking which one is universally best.

How to Structure an Authentication Interview Answer

For every design, identify four things: actors, trust boundaries, credentials, and decisions. Who is the user or workload? Which system authenticates it? What credential crosses each boundary? Which component makes the final authorization decision?

Then describe lifecycle and failure behavior. Cover issuance, validation, storage, expiration, rotation, revocation, logout, and incident response. A flow diagram without a stolen-token or disabled-user story is only the happy path.

Authentication and Authorization Interview Questions

1. What is the difference between authentication and authorization?

Authentication answers, "Which subject is acting, and how was that identity established?" Authorization answers, "May this subject perform this action on this resource in this context?" The order matters, but successful authentication never implies broad permission.

In the invoice incident, the JWT may correctly identify the user. The defect is that the API did not verify the relationship between that user, the requested invoice, and the tenant in the current request.

2. Where should authorization be enforced?

Enforce it at every protected entry point and close to the resource or domain action being protected. Middleware can authenticate the caller and enforce coarse scopes, but the service that understands invoice ownership must still decide whether this caller can read this invoice.

Follow deny-by-default behavior and check permission on every request. Random or unguessable object IDs reduce enumeration, but they do not replace object-level authorization.

3. When would you use RBAC or ABAC?

RBAC maps users to roles and roles to permissions. It works well when job functions are stable and explainable, but role combinations can multiply as products, tenants, and exceptions grow.

ABAC evaluates subject, resource, action, and sometimes environment attributes against policy. For example, an account manager may edit a customer record only when both belong to the same region and the record is not under legal hold. Use the simplest model that expresses the business rule without hiding decisions in scattered conditionals.

OAuth and OpenID Connect Interview Questions

4. Is OAuth an authentication protocol?

OAuth 2.0 is an authorization framework for delegated access. Treating an access token or a successful authorization response as proof of login can create identity confusion because OAuth alone does not define the authentication claims and validation contract a client needs.

OpenID Connect adds that identity layer. It defines an ID token and rules that let a client verify authentication performed by an OpenID Provider.

5. Why use Authorization Code with PKCE?

The client creates a secret code_verifier and sends its derived code_challenge with the authorization request. When exchanging the returned code, it must present the original verifier. A stolen code cannot be redeemed without that value.

The current OAuth 2.0 Security Best Current Practice recommends code-based flows over the implicit grant and requires PKCE support for public clients. It also says the resource owner password credentials grant must not be used.

6. What do state, nonce, and PKCE each protect?

state binds the authorization response to client state and is commonly used to defend the redirect flow against request forgery. PKCE binds an authorization code to the client instance that started the flow. In OIDC, nonce binds the client session to the ID token and helps detect replay or code-injection scenarios.

They are related controls, not interchangeable strings. A strong answer states where each value is generated, stored, returned, validated, and discarded.

7. What is the difference between an ID token and an access token?

An ID token tells the client about the user's authentication and contains claims intended for that client. An access token is presented to a resource server to request authorized access.

Do not send an ID token to an API merely because it is a signed JWT. The API needs a token intended for its audience and must enforce scopes or other policy for the requested operation.

8. How do you authenticate service-to-service traffic?

For a workload acting on its own behalf, a confidential client can obtain an access token without a human user, commonly through the client credentials grant. Restrict the token to the intended resource and actions, authenticate the workload strongly, and keep credentials short-lived.

Do not invent a user identity for the service. Preserve whether an action came from a workload, a user, or a service acting on behalf of a user, because auditing and authorization may differ.

JWT Interview Questions

9. What must an API validate in a JWT?

Use a trusted library and an explicit allowlist of acceptable algorithms. Verify the signature with keys bound to the expected issuer, then validate issuer, audience, expiration, not-before time when present, and the token type or profile expected by that endpoint.

Only after token validation should the API interpret identity, scopes, roles, or other claims. The JWT Security Best Current Practices specifically requires algorithm verification and audience validation when tokens can target multiple recipients.

10. Why is decoding a JWT not verification?

The header and payload are base64url-encoded and can be read or changed by anyone holding the token. Decoding reveals claims; signature verification establishes whether the protected content came from a trusted issuer and was not modified.

Even a valid signature is only one check. A token from the wrong issuer or for another audience must still be rejected.

11. How do you revoke a JWT?

There is no universal instant-revocation property in a self-contained JWT. Common designs combine short-lived access tokens with revocable refresh tokens, a session or token version, a denylist for urgent cases, key rotation for key compromise, or token introspection when current server-side state is required.

State the consistency target. "Disable this user within 30 seconds" leads to a different design than "permissions converge within a 10-minute access-token lifetime."

12. Are JWTs better than server-side sessions?

Not automatically. Local JWT validation can reduce a central session lookup and carry useful claims, but the claims can become stale, revocation gets harder, and every verifier must apply the same validation contract.

Opaque sessions make immediate invalidation and "log out all devices" straightforward, but require a highly available store or a deliberate caching strategy. Choose from lifecycle and trust requirements, not the word "stateless."

Session Interview Questions

13. What should a secure browser session look like?

Give the browser a high-entropy opaque identifier and keep identity and privilege state on the server. Send the identifier only over HTTPS in a cookie with Secure, HttpOnly, and an intentional SameSite policy; narrow domain and path scope where practical.

Set idle and absolute expiration, rotate the identifier after authentication and privilege changes, and invalidate it server-side on logout. Cookie protections reduce specific risks but do not repair a broken authorization policy.

14. What is session fixation?

Session fixation happens when an attacker causes a victim to use an identifier the attacker already knows, then waits for the victim to authenticate that session. Regenerate the session identifier when authentication or privilege level changes and accept only identifiers issued by the application.

15. How are CSRF and XSS different for session security?

A browser automatically attaches cookies to matching requests, so a malicious site may attempt to trigger an authenticated action through CSRF. Use an appropriate SameSite policy plus a proven anti-CSRF pattern for state-changing requests where needed.

HttpOnly prevents JavaScript from reading the cookie value, but an XSS payload can still make requests from the victim's origin. Prevent XSS and treat cookie flags as layered controls, not a complete defense.

16. How would you implement "log out all devices"?

Store sessions by user and revoke all active records, or advance a per-user session version checked on future requests. Also revoke or rotate refresh credentials that could mint new access tokens after logout.

Define what happens across regions and caches. The interview-worthy detail is the maximum revocation delay and how high-risk events such as password reset or account compromise bypass normal cache staleness.

A Complete Authentication and Authorization Walkthrough

Consider a multi-tenant SaaS application. The browser starts an OIDC Authorization Code flow with PKCE. After validating the response and ID token, a backend-for-frontend creates an opaque application session in a hardened cookie and stores any provider tokens server-side.

When the user requests invoice inv_42, the API does not stop after reading a valid identity. It loads the invoice, derives the action, tenant, ownership, and relevant policy, then makes a deny-by-default decision:

claims = verify_token(
  token,
  allowed_algorithms,
  expected_issuer,
  api_audience,
  current_time
)

invoice = load_invoice(request.invoice_id)
require authorize(
  subject = claims.sub,
  action = "invoice:read",
  resource_tenant = invoice.tenant_id,
  request_tenant = request.tenant_id
)

For an access token, verification also includes the token profile, scopes, and intended resource. For a server-side session, the first step becomes an opaque session lookup. The final resource authorization decision remains necessary in both designs.

If an employee is disabled, the system revokes sessions and refresh credentials immediately, then relies on the defined access-token lifetime or introspection path for remaining tokens. The team can state the worst-case delay instead of claiming revocation is instantaneous everywhere.

How Interviewers Score Authentication Answers

A Focused 5-Day Preparation Plan

Combine the technical mock with behavioral and leadership interview practice. Senior follow-ups often ask how you migrated a legacy auth system, handled an urgent security exception, or convinced product teams to adopt stronger defaults.

Frequently Asked Questions

Is an access token always a JWT?

No. OAuth treats the access token as a credential and does not require every deployment to use the JWT format. An authorization server can issue an opaque token that the resource server validates through introspection or another trusted server-side mechanism.

Should a browser store JWTs in localStorage?

JavaScript-readable persistent storage exposes the token to any successful XSS in that origin. Where the architecture supports it, keep reusable credentials server-side and use a hardened HttpOnly session cookie or backend-for-frontend. Whatever design you choose must address both XSS and CSRF rather than trading one away silently.

Do roles inside a valid JWT solve authorization?

No. Roles can provide useful input, but the service must still decide whether the subject can perform the requested action on the specific resource. Tenant boundaries, ownership, current account state, and policy changes may not be captured by a broad role claim.

What is the biggest authentication interview mistake?

Jumping directly to a technology. First define who trusts whom, what the credential represents, which component validates it, where authorization happens, and how access ends. Only then choose OAuth flows, token formats, cookie settings, and storage.

Practice the Trust Boundaries

The strongest answers do not merely draw a login arrow. They state what every token is for, what each validation proves, which data remains server-side, where the resource decision occurs, and how stolen or stale credentials stop working.

Use PracHub to practice real interview questions with written solutions, then rehearse this multi-tenant scenario aloud. For a specific loop, add company-specific interview prep and adapt the threat model to that company's product.

Official Sources

• IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
• OpenID Foundation: OpenID Connect Core 1.0
• IETF RFC 8725: JSON Web Token Best Current Practices
• IETF RFC 7662: OAuth 2.0 Token Introspection
• IETF RFC 7009: OAuth 2.0 Token Revocation
• OWASP: Session Management Cheat Sheet
• OWASP: Authorization Cheat Sheet
• NIST SP 800-162: Attribute Based Access Control