Session vs Token-Based Authentication in REST APIs: Cookies, JWTs, and Security Essentials Quiz

Test your understanding of session-based versus token-based authentication for REST APIs, including differences in cookies, JWTs, refresh tokens, expiration, revocation, and CSRF protection. This easy-level quiz helps you reinforce key concepts and best practices in modern API security.

1. Session State Storage Location

   Where is user session data typically stored when using classic session-based authentication for REST APIs?

   1. In the request URL
   2. On the user's operating system
   3. Inside the user's JWT
   4. On the server side

   Explanation: Session-based authentication stores session data on the server, which allows the server to track user states securely. In token-based authentication using JWTs, most data is stored in the token itself, not on the server. Storing session data in the request URL or on the user's operating system is insecure and not a standard practice for API authentication.

2. Statelessness of JWTs

   Why are JWTs (JSON Web Tokens) considered stateless in token-based authentication for REST APIs?

   1. JWTs use session IDs to find data on the server
   2. JWTs store data in browser cookies
   3. JWTs carry all necessary user data within themselves
   4. JWTs require server-side lookups for user info

   Explanation: JWTs are stateless because they encapsulate user information within the token, removing the need for server-side session storage. Using server-side lookups or session IDs undermines statelessness. JWTs can be stored in cookies, but that is a storage mechanism, not the reason for statelessness.

3. Session ID Purpose

   What is the main purpose of a session ID in a session-based authentication system for REST APIs?

   1. To encrypt HTTP headers
   2. To reference the user's session on the server
   3. To store the user's password
   4. To generate new API routes

   Explanation: A session ID uniquely identifies a user's session stored on the server, allowing the server to recognize authenticated users. Session IDs do not store passwords, generate routes, or handle header encryption. The other options describe functions not associated with session IDs.

4. JWT Expiration Field

   Which field in a JWT defines when the token will become invalid for authentication purposes?

   1. sig
   2. aud
   3. exp
   4. nbf

   Explanation: The 'exp' (expiration) field in a JWT specifies when the token expires and is no longer valid. 'aud' stands for audience, 'nbf' means not before (the start time a token is valid), and 'sig' refers to the token's signature section. Only 'exp' directly controls the expiration.

5. Refresh Token Role

   What is the primary role of a refresh token in a token-based authentication system for REST APIs?

   1. To replace the user's password
   2. To encrypt all user data
   3. To log the user out automatically
   4. To obtain a new access token when the old one expires

   Explanation: The refresh token is used to get a new access token without requiring the user to log in again, extending the authenticated session securely. It does not log users out, encrypt data, or replace passwords. Those tasks are handled differently in authentication systems.

6. CSRF Protection in REST APIs

   Which authentication method is more vulnerable to CSRF attacks in REST API contexts, and why?

   1. JWT tokens with httpOnly cookies since they are read-only
   2. JWT stored in localStorage because it's same-domain only
   3. Cookie-based session authentication because browsers automatically send cookies
   4. Bearer tokens in Authorization headers because they're auto-attached

   Explanation: Cookie-based authentication is more vulnerable to CSRF because browsers attach cookies automatically to each request, which can be exploited. JWTs in localStorage or as Bearer tokens in headers are not automatically sent, reducing CSRF risk. httpOnly cookies add some protection but still are included in requests.

7. Session Invalidation on Logout

   In session-based authentication, how can a server immediately revoke a user's session after logout?

   1. Change the user's password
   2. Delete the session data from the server-side store
   3. Modify the browser's color scheme
   4. Update the user's profile picture

   Explanation: By deleting the session data on the server, the server can invalidate the session immediately, making further requests unauthorized. Changing a password, changing a profile picture, or updating browser settings do not directly affect the session's validity.

8. Token Revocation in JWT-based Auth

   Why is immediate token revocation challenging with JWT-based authentication for REST APIs?

   1. JWTs require a server-side session lookup
   2. JWTs are linked to a central blacklist updated in real time
   3. JWTs are self-contained and remain valid until expiration
   4. JWTs are always stored in plaintext

   Explanation: JWTs do not depend on server-state and are valid until their expiration, so revoking them before that point is difficult unless additional infrastructure like blacklists is used. JWTs are not always stored in plaintext, and normally are not tied to a central real-time blacklist. JWTs do not require server session lookups for validation.

9. Secure JWT Storage in Browsers

   Which location is recommended for storing JWTs in the browser to reduce the risk of XSS attacks?

   1. localStorage
   2. httpOnly cookies
   3. DOM variables
   4. indexDB

   Explanation: httpOnly cookies cannot be accessed by JavaScript, making them more secure against XSS attacks than localStorage, indexDB, or DOM variables. localStorage and indexDB are accessible to client-side scripts, increasing exposure. DOM variables are also vulnerable in case of XSS.

10. Bearer Token Usage

    How is a Bearer token typically sent when authenticating requests to a REST API?

    1. As a query parameter in the URL
    2. In the Authorization HTTP header
    3. In a custom HTTP body field
    4. As part of the domain name

    Explanation: Bearer tokens should be transmitted in the Authorization header to ensure security and standardization. Sending tokens in URLs, body fields, or domain names can expose them or cause compatibility issues. The Authorization header is specifically intended for such credentials.

11. Session vs. Token Scalability

    Which authentication approach generally scales better across distributed REST API servers?

    1. Session-based with in-memory storage
    2. Session-based with browser cache
    3. Token-based (e.g., JWT)
    4. Session-based with desktop app tokens

    Explanation: Token-based approaches like JWTs are stateless, so any server can verify the token, making scaling easier. Session-based methods with in-memory storage require sharing state across servers, which is less efficient. Browser cache and desktop app tokens are not practical or secure for scaling authentication across distributed systems.

12. Access Token Purpose

    For REST API authentication, what is the main purpose of an access token?

    1. To display user interface components
    2. To authorize specific API requests on behalf of a user
    3. To transmit the user's private key
    4. To serve as a permanent user identifier

    Explanation: An access token is used to authorize the client to access specific API endpoints as a certain user. It is not used to transmit private keys, display UI components, or serve as a permanent identifier; those are handled by separate mechanisms.

13. Cookie SameSite Attribute Role

    Which cookie attribute reduces the risk of CSRF attacks in REST API authentication?

    1. domain
    2. SameSite
    3. expires
    4. max-age

    Explanation: The SameSite attribute tells the browser not to send cookies with cross-site requests, which helps defend against CSRF. While 'expires' and 'max-age' control the cookie's life and 'domain' restricts its scope, neither are designed specifically for CSRF mitigation.

14. Token Expiry Advantage

    What is one main security advantage of making REST API tokens expire after a short period?

    1. Increases user typing speed
    2. Reduces network latency
    3. Limits the window for misuse if the token is stolen
    4. Lowers password complexity

    Explanation: Short-lived tokens minimize the potential damage an attacker can do with a compromised token by restricting its validity period. Typing speed, network latency, and password complexity are unrelated to token expiration and do not have an impact on token security.

15. Session vs. Token in Mobile Apps

    Which authentication method is usually preferred in mobile apps interacting with REST APIs?

    1. Session-based authentication with volatile cookies
    2. Token-based authentication
    3. Session-based authentication with strict CORS
    4. Operating system password caching

    Explanation: Token-based authentication is preferred for mobile apps due to its statelessness and flexibility across platforms. Session-based methods and volatile cookies are less mobile-friendly, while operating system password caching is not a standard authentication approach for REST APIs.

16. Invalidating Refresh Tokens

    How can a REST API server revoke a user's refresh token before its scheduled expiration?

    1. Shorten the token’s name
    2. Remove or blacklist the token on the server
    3. Delete the front-end application's cache
    4. Update the user's email address

    Explanation: To immediately revoke a refresh token, the server can remove or add it to a blacklist, ensuring it cannot be reused. Deleting the application's cache, shortening the token’s name, or updating the user's email does not directly revoke a token’s validity.