Authentication vs Authorization: Essentials and Common Pitfalls Quiz

Test and reinforce your understanding of authentication versus authorization, sessions versus tokens, role-based access, permission checks, and common pitfalls in identity management. This quiz covers all the essential concepts and practical scenarios relevant to secure application design.

1. Distinguishing AuthN and AuthZ

   Which process verifies the identity of a user before allowing access to a system?

   1. Authorization
   2. Automation
   3. Authentication
   4. Auditing

   Explanation: Authentication is the process that confirms who a user is, typically by checking credentials like passwords or biometrics. Authorization, on the other hand, determines what an authenticated user is allowed to do. Automation relates to performing tasks without manual intervention, and auditing refers to reviewing actions or changes. Only authentication directly addresses identity verification.

2. AuthZ Scenario

   If a user can view their account information but cannot edit it, which concept is being applied?

   1. Authorization
   2. Automation
   3. Authentication
   4. Announcement

   Explanation: Authorization controls what an authenticated user can and cannot do, such as restricting editing rights. Authentication merely checks identity, while automation and announcement are unrelated jargon intended to distract. This scenario specifically refers to limiting actions post-authentication.

3. Sessions vs Tokens Basics

   What is a key difference between session-based and token-based authentication schemes?

   1. Tokens require users to log in every time.
   2. Session-based authentication is only for mobile apps.
   3. Sessions are stored on the server; tokens are usually stored on the client.
   4. Tokens store user passwords; sessions do not.

   Explanation: Session-based schemes keep session data on the server and track users via session IDs, while tokens (like JWTs) are typically stored and managed client-side. Tokens do not store passwords and are not inherently tied to frequent logins. Session authentication is not exclusive to mobile apps; it is widely used on the web, while the distractors describe incorrect characteristics.

4. User Login Example

   During a login process, which comes first: authentication or authorization?

   1. Authentication
   2. Both happen at the same time
   3. Neither is required
   4. Authorization

   Explanation: Authentication always precedes authorization; you need to verify who the user is before checking what they are allowed to access. Authorization only occurs once the user’s identity has been confirmed. Saying both happen together or that neither is required is incorrect and ignores the logical sequence.

5. Role-based Access

   A bank system allows tellers to view accounts and managers to approve loans. What is being used to enforce these differences?

   1. Session timeouts
   2. Role-based access control
   3. Client-side caching
   4. Token expiration

   Explanation: Role-based access control (RBAC) assigns permissions based on job roles, giving different rights to tellers and managers. Session timeouts and token expiration relate to session management, not access decisions. Client-side caching helps performance, not access enforcement.

6. Permission Checks Practical

   Which process checks if a user is allowed to delete a file after logging in?

   1. Token refresh
   2. Permission check
   3. Session creation
   4. Two-factor authentication

   Explanation: A permission check specifically evaluates whether an authenticated user has rights to perform an action like deleting a file. Two-factor authentication adds a security step to logging in but doesn't manage specific permissions. Token refresh and session creation manage authentication, not granular access control.

7. Common AuthZ Pitfall

   What is a common authorization mistake in web apps?

   1. Requiring strong passwords at signup.
   2. Supporting multiple login methods.
   3. Checking only if user is logged in, not whether they have permission.
   4. Enforcing SSL/TLS for all connections.

   Explanation: It's a common pitfall to only check for authentication and forget to enforce authorization, potentially exposing unauthorized data or actions. Requiring strong passwords and enforcing SSL are good security practices, and supporting multiple login methods often enhances usability, not representing pitfalls in authorization.

8. Session Expiry Consequences

   What can happen if session expiration is not properly implemented?

   1. Users can never log in successfully.
   2. Users may remain logged in indefinitely, risking unauthorized access.
   3. Permission checks improve automatically.
   4. Users receive stronger authentication protection.

   Explanation: Without timely session expiration, old sessions may stay valid, increasing the risk of unauthorized use if someone else gains access. It does not enhance security or permission checks. Saying users can never log in is incorrect; the real threat is prolonged session life and security exposure.

9. Token Security Issue

   Why is it risky to store access tokens in browser local storage?

   1. Tokens perform role checks automatically.
   2. Tokens cannot be encoded.
   3. They are accessible to JavaScript, making them vulnerable to cross-site scripting (XSS) attacks.
   4. Local storage deletes data every hour.

   Explanation: Tokens in local storage are susceptible to theft if predators exploit XSS vulnerabilities. Tokens being encoded or stored has no bearing on this risk, and local storage does not automatically delete data. Tokens themselves do not run permission or role checks; they simply carry information.

10. Stateless vs Stateful

    What does it mean when token-based authentication is called 'stateless'?

    1. Users must provide a state name at login.
    2. The server stores all user login history.
    3. The server does not keep track of session data for each user.
    4. Tokens are encrypted with state codes.

    Explanation: Stateless token-based systems do not hold user session details on the server, relying instead on tokens for information. Storing all history, encrypting with state codes, or asking for a state name is irrelevant to the meaning of 'stateless' in this context.

11. Sensitive Operation Scenario

    A user tries to update an admin-only resource but lacks proper rights. The system denies the request. Which process prevented the action?

    1. Anonymization
    2. Allocation
    3. Authorization
    4. Authentication

    Explanation: Authorization determines if the user has the necessary rights for sensitive actions like updating admin resources. Authentication would only ensure the user is logged in, not if they have admin privileges. Anonymization and allocation are unrelated to access control checks.

12. Misconception Check

    Which is a misconception about sessions and tokens?

    1. Sessions are typically managed on the server side.
    2. Tokens can include user roles and claims.
    3. Sessions support automatic expiration.
    4. Tokens are always more secure than sessions.

    Explanation: It's incorrect to assume tokens are always more secure; both methods have strengths and weaknesses depending on implementation. Sessions do usually live on the server, tokens can carry user-related data, and sessions can expire. The distractors are all examples of correct, not mistaken, beliefs about sessions or tokens.

13. Role vs Permission

    How does a role differ from a permission in access control?

    1. Roles only exist for tokens, not sessions.
    2. A role is a collection of permissions, while a permission is an individual access right.
    3. A permission is a job title, but a role is not.
    4. Permissions are used only during login.

    Explanation: Roles group multiple permissions to make management easier, while permissions are defined actions a user can perform. Permissions are not job titles, nor are either restricted by session or token usage. Permissions are used for more than just logging in.

14. Least Privilege Principle

    What is the principle of 'least privilege'?

    1. Sessions expire every second.
    2. Users are granted only the permissions necessary to do their job.
    3. Every user receives the same access rights.
    4. Tokens are never encrypted.

    Explanation: The least privilege principle restricts users’ access to only what’s required, reducing security risks. Granting everyone the same access, not encrypting tokens, and instant session expiry all misrepresent the principle or have no connection to privilege management.

15. Implicit vs Explicit Permission Check

    Why should explicit permission checks be used in web APIs?

    1. Because implicit checks are always more secure.
    2. To avoid any form of auditing.
    3. To hide endpoints from all users.
    4. To ensure actions are allowed for each request regardless of authentication alone.

    Explanation: Explicit permission checks verify each action is authorized, not just that the user is logged in, thus improving security. Implicit checks are less reliable, hiding endpoints is not sufficient, and auditing avoidance is detrimental. Only option A reflects the right security practice.