Backend Development Authentication, Authorization and Security Syllabus

Authentication, Authorization and Security syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Authentication, Authorization and Security in Backend Development, not a summary of it.

1. 1

   Authentication Fundamentals

   4 topics

   • Password Hashing and Salting
   • Session-Based Authentication
   • Token-Based Authentication
   • Multi-Factor Authentication
2. 2

   Tokens and Federated Identity

   4 topics

   • JSON Web Tokens (JWT)
   • OAuth 2.0 Flows
   • OpenID Connect
   • Single Sign-On (SSO) and SAML
3. 3

   Authorization Models

   4 topics

   • Role-Based Access Control (RBAC)
   • Attribute-Based Access Control (ABAC)
   • Access Control Lists
   • Policy Enforcement
4. 4

   Web Application Security

   5 topics

   • OWASP Top 10
   • Injection Attacks
   • Cross-Site Scripting (XSS)
   • Cross-Site Request Forgery (CSRF)
   • Security Headers and CSP
5. 5

   Cryptography and Data Protection

   5 topics

   • Symmetric and Asymmetric Encryption
   • Hashing vs Encryption
   • TLS and Certificate Management
   • Secrets Management and Vaults
   • Data Privacy and Compliance (GDPR)

Authentication, Authorization and Security flashcards for Backend Development

24 of 51 cards from the Authentication, Authorization and Security deck — real questions with worked answers.

1. What is the difference between hashing and encryption when storing passwords?

   Hashing is a one-way function that cannot be reversed, so the original password can never be recovered; encryption is two-way (reversible with a key). Passwords should be hashed, not encrypted, so a database breach does not directly expose plaintext passwords.

2. What is a salt in password hashing, and what attack does it defend against?

   A salt is a unique random value added to each password before hashing. It ensures identical passwords produce different hashes, defeating precomputed rainbow-table attacks and preventing attackers from seeing which users share the same password.

3. Why are fast hash functions like MD5 or SHA-256 unsuitable for password storage, and what should be used instead?

   Fast hashes let attackers try billions of guesses per second in brute-force/dictionary attacks. Use deliberately slow, memory-hard adaptive functions such as bcrypt, scrypt, Argon2, or PBKDF2, which include a configurable work/cost factor.

4. What is a pepper, and how does it differ from a salt?

   A pepper is a secret value added to passwords before hashing, but unlike a salt it is the same for all users and stored separately (e.g., in an HSM or app config), not in the database. A salt is unique per user and stored alongside the hash.

5. In session-based authentication, where is the session state stored and what does the client hold?

   The session state is stored on the server (in memory, a database, or a cache like Redis). The client holds only an opaque session ID, typically in a cookie, which the server looks up on each request.

6. What cookie attributes should protect a session cookie, and what does each do?

   HttpOnly (blocks JavaScript access, mitigating XSS theft), Secure (sent only over HTTPS), SameSite (restricts cross-site sending, mitigating CSRF), and appropriate Domain/Path and expiration settings.

7. Contrast stateful session-based auth with stateless token-based auth regarding server storage and scalability.

   Session-based auth is stateful: the server stores session data and must share it across instances, complicating horizontal scaling. Token-based auth is stateless: the token itself carries the identity/claims, so any server can validate it without shared session storage, easing scaling.

8. What is a key trade-off of stateless tokens regarding revocation?

   Because a self-contained token is valid until it expires and requires no server lookup, it cannot be easily revoked mid-lifetime. Mitigations include short expiry times, refresh tokens, or maintaining a server-side denylist (which reintroduces state).

9. What are the two factors combined in a bearer token + refresh token scheme, and what is each used for?

   A short-lived access token authorizes API requests; a long-lived refresh token is used only to obtain new access tokens when the old one expires, limiting exposure if an access token is stolen.

10. What does the acronym MFA stand for, and what are the three classic authentication factor categories?

    Multi-Factor Authentication. The categories are: something you know (password/PIN), something you have (phone, hardware token), and something you are (biometrics like fingerprint or face).

11. How does TOTP (Time-based One-Time Password) generate its code?

    TOTP hashes a shared secret together with the current time counter (typically a 30-second window) using HMAC, then truncates the result to a 6-8 digit code. Both server and client compute the same code independently: $TOTP = HOTP(K, \lfloor T/T_{0} \rfloor)$.

12. Why is an authenticator app (TOTP) or hardware key generally considered stronger than SMS-based MFA?

    SMS is vulnerable to SIM-swapping, SS7 network interception, and phishing relay. TOTP secrets never leave the device, and hardware keys (FIDO2/WebAuthn) additionally bind the credential to the origin, resisting phishing entirely.

13. What are the three structural parts of a JWT, and how are they separated?

    Header, Payload (claims), and Signature, each Base64URL-encoded and separated by dots: $header.payload.signature$.

14. Is the payload of a standard signed JWT (JWS) encrypted? What is the security implication?

    No. A signed JWT is only Base64URL-encoded and signed, so anyone can read the payload. It provides integrity/authenticity but not confidentiality; never put secrets in it. For confidentiality use JWE (encrypted JWT).

15. Name four standard registered JWT claims and their meanings.

    iss (issuer), sub (subject/user), aud (audience/intended recipient), exp (expiration time), plus iat (issued at), nbf (not before), and jti (unique token ID).

16. What is the 'alg: none' JWT vulnerability?

    If a server accepts the 'none' algorithm, an attacker can strip the signature and forge arbitrary claims, since no signature verification occurs. Servers must reject 'none' and enforce an expected algorithm whitelist.

17. Compare HS256 and RS256 JWT signing algorithms.

    HS256 is HMAC with a symmetric shared secret—the same key signs and verifies. RS256 is RSA asymmetric—a private key signs and a public key verifies, so verifiers need not hold the signing secret. RS256 suits distributed systems and third-party verification.

18. In OAuth 2.0, define the four roles: resource owner, client, authorization server, and resource server.

    Resource owner: the user who owns the data. Client: the app requesting access. Authorization server: issues tokens after authenticating the owner. Resource server: hosts the protected resources and accepts access tokens.

19. What are the steps of the OAuth 2.0 Authorization Code flow?

    1) Client redirects user to the authorization server. 2) User authenticates and consents. 3) Server redirects back with an authorization code. 4) Client exchanges the code (plus its secret) at the token endpoint for an access token (and optional refresh token).

20. What is PKCE in OAuth 2.0 and which clients need it?

    Proof Key for Code Exchange. The client generates a random code_verifier, sends its hash (code_challenge) in the authorization request, then sends the verifier at token exchange. It protects public clients (SPAs, mobile apps) from authorization-code interception, since they cannot safely store a client secret.

21. Why is the OAuth 2.0 Implicit flow now discouraged?

    It returns the access token directly in the URL fragment, exposing it to browser history, referrer leakage, and interception, with no client authentication. The Authorization Code flow with PKCE is now recommended instead.

22. What is the OAuth 2.0 Client Credentials grant used for?

    Machine-to-machine authentication where no user is involved. The client authenticates with its own credentials to obtain an access token for its own resources (e.g., a backend service calling an API).

23. Fundamentally, what is OAuth 2.0 designed for, and what is it NOT designed for?

    OAuth 2.0 is an authorization framework for delegating access to resources (permissions). It is NOT an authentication protocol for identifying users; using access tokens alone to prove identity is insecure. OpenID Connect adds authentication on top.

24. What does OpenID Connect (OIDC) add on top of OAuth 2.0?

    An identity layer. It introduces the ID token (a JWT with authenticated user identity claims), a standardized /userinfo endpoint, and the 'openid' scope, turning OAuth's authorization into authentication.

See more Authentication, Authorization and Security flashcards →

Planning Authentication, Authorization and Security for Backend Development

Authentication, Authorization and Security (Backend Development) FAQ