🌍 Backend Development · subject
Backend Development Authentication, Authorization and Security Syllabus
The Authentication, Authorization and Security syllabus for Backend Development in full: 5 chapters and 22 topics, every one listed below, plus 51 Authentication, Authorization and Security flashcards with answers.
Authentication, Authorization and Security syllabus: all 5 chapters
Expand any chapter to see its topics and sub-topics.
-
Authentication Fundamentals
4 topics- Password Hashing and Salting
- Session-Based Authentication
- Token-Based Authentication
- Multi-Factor Authentication
-
Tokens and Federated Identity
4 topics- JSON Web Tokens (JWT)
- OAuth 2.0 Flows
- OpenID Connect
- Single Sign-On (SSO) and SAML
-
Authorization Models
4 topics- Role-Based Access Control (RBAC)
- Attribute-Based Access Control (ABAC)
- Access Control Lists
- Policy Enforcement
-
Web Application Security
5 topics- OWASP Top 10
- Injection Attacks
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
- Security Headers and CSP
-
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)
Backend Development Authentication, Authorization and Security flashcards — 51 questions with answers
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.
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.
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.
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.
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.
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.
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.
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).
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.
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).
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)$.
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.
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$.
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).
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).
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.
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.
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.
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).
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.
Show the other 31 Authentication, Authorization and Security flashcards
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.
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).
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.
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.
What is the difference between an OIDC ID token and an OAuth access token?
The ID token proves who the user is (identity claims) and is intended for the client. The access token grants permission to call resource APIs and is intended for the resource server. They serve authentication vs. authorization respectively.
Define Single Sign-On (SSO).
An authentication scheme where a user logs in once with a single set of credentials and gains access to multiple independent applications/services without re-authenticating to each.
What does SAML stand for, what format does it use, and what is the core artifact it exchanges?
Security Assertion Markup Language. It is XML-based and exchanges signed SAML assertions containing authentication and attribute statements between an Identity Provider (IdP) and a Service Provider (SP).
Compare SAML and OIDC for SSO.
SAML is XML-based, mature, and common in enterprise/web-SSO. OIDC is JSON/JWT-based, built on OAuth 2.0, and better suited to modern mobile and single-page applications and APIs. Both federate identity via an IdP.
In SAML, what are the roles of the Identity Provider (IdP) and Service Provider (SP)?
The IdP authenticates the user and issues assertions. The SP is the application the user wants to access; it trusts and consumes the IdP's assertions to grant access without authenticating the user itself.
Define Role-Based Access Control (RBAC).
An access-control model where permissions are assigned to roles, and users are assigned roles. Access is determined by the user's role(s) rather than by individual user identity, simplifying administration.
Define Attribute-Based Access Control (ABAC) and how it differs from RBAC.
ABAC grants access based on policies evaluating attributes of the subject, resource, action, and environment (e.g., department, time, location). Unlike RBAC's fixed roles, ABAC is more dynamic and fine-grained, expressing context-aware rules.
Give an example ABAC policy that RBAC alone could not easily express.
"Allow access only if user.department == resource.department AND time is between 9am-5pm AND user.clearance >= resource.classification." This combines multiple contextual attributes rather than a single static role.
What is an Access Control List (ACL)?
A list attached to a resource (object) that specifies, per subject (user or group), which operations (read, write, execute) are permitted or denied. It is object-centric authorization.
Contrast the object-centric ACL model with the capability-based model.
An ACL is attached to the object and lists who may access it (answers "who can access this file?"). A capability is held by the subject as an unforgeable token/reference granting rights (answers "what can this user access?").
In access control, distinguish the PEP, PDP, and PAP.
PEP (Policy Enforcement Point) intercepts requests and enforces the decision. PDP (Policy Decision Point) evaluates policies and returns permit/deny. PAP (Policy Administration Point) is where policies are authored and managed. Often a PIP (Information Point) supplies attributes.
What is the principle of least privilege?
Every user, process, or system should be granted only the minimum permissions necessary to perform its function, and no more, reducing the attack surface and blast radius of a compromise.
What is the difference between a default-deny (whitelist) and default-allow (blacklist) authorization policy, and which is safer?
Default-deny blocks everything except explicitly permitted actions; default-allow permits everything except explicitly forbidden actions. Default-deny is safer because forgotten cases fail closed (denied) rather than being unintentionally exposed.
What is the OWASP Top 10?
A regularly updated awareness document listing the ten most critical web application security risks, published by the Open Worldwide Application Security Project to guide developers on the most common and impactful vulnerabilities.
Name five categories from the OWASP Top 10 (2021).
Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration (others: Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, Server-Side Request Forgery).
What category ranked #1 in the OWASP Top 10 2021?
Broken Access Control—flaws that let users act outside their intended permissions (e.g., accessing other users' data, privilege escalation, IDOR).
What is an injection attack, and what is the root cause?
An attack where untrusted input is interpreted as part of a command or query (SQL, OS, LDAP, NoSQL). The root cause is mixing untrusted data with code/commands without proper separation, so the data is executed as instructions.
What is the primary defense against SQL injection?
Parameterized queries / prepared statements, which bind user input strictly as data separate from the SQL code so it can never be interpreted as commands. Supplement with input validation, least-privilege DB accounts, and ORMs.
What is Cross-Site Scripting (XSS)?
An injection vulnerability where an attacker injects malicious scripts into web content that executes in other users' browsers, enabling session/cookie theft, defacement, or actions on the victim's behalf.
Distinguish stored, reflected, and DOM-based XSS.
Stored: malicious script is persisted on the server (e.g., in a comment) and served to victims. Reflected: script is embedded in a request and reflected back in the immediate response (e.g., via a link). DOM-based: the vulnerability is in client-side JavaScript manipulating the DOM with untrusted data, never reaching the server.
What is the primary defense against XSS?
Context-aware output encoding/escaping of untrusted data when rendering into HTML, attributes, JS, or URLs, plus input validation, using safe frameworks/APIs (avoiding innerHTML), and a Content Security Policy as defense in depth.
What is Cross-Site Request Forgery (CSRF)?
An attack that tricks an authenticated user's browser into sending a forged state-changing request to a site where they are logged in, exploiting automatically-sent credentials (cookies) to perform actions without consent.
Name the main defenses against CSRF.
Anti-CSRF synchronizer tokens (unpredictable per-session/per-request token validated server-side), the SameSite cookie attribute, double-submit cookies, and verifying Origin/Referer headers for state-changing requests.
Why does the SameSite=Lax or Strict cookie attribute help mitigate CSRF?
It instructs the browser not to send the cookie on cross-site requests (Strict) or only on top-level navigations (Lax), so a forged request from an attacker's site arrives without the victim's authentication cookie.
What does the Content-Security-Policy (CSP) header do, and which attack does it primarily mitigate?
CSP restricts which sources the browser may load scripts, styles, images, etc. from (e.g., script-src 'self'), primarily mitigating XSS and data-injection by blocking inline/unauthorized scripts.
What does the HTTP Strict-Transport-Security (HSTS) header enforce?
It forces browsers to use HTTPS-only connections to the site for a specified max-age, preventing protocol-downgrade and SSL-stripping man-in-the-middle attacks and blocking use of the plain HTTP version.
Compare symmetric and asymmetric encryption in terms of keys, speed, and typical use.
Symmetric uses one shared secret key for both encryption and decryption—fast, ideal for bulk data (e.g., AES). Asymmetric uses a public/private key pair (encrypt with one, decrypt with the other)—slower, used for key exchange, digital signatures, and identity (e.g., RSA, ECC). TLS combines both: asymmetric to exchange a symmetric session key.
Backend Development Authentication, Authorization and Security FAQ
What is in the Backend Development Authentication, Authorization and Security syllabus?
Backend Development Authentication, Authorization and Security is split into 5 chapters: Authentication Fundamentals, Tokens and Federated Identity, Authorization Models, Web Application Security and Cryptography and Data Protection. Together they contain 22 topics.
How many chapters are in Backend Development Authentication, Authorization and Security?
5 chapters, containing 22 topics. The largest chapter is Web Application Security, with 5 topics.
Are there flashcards for Backend Development Authentication, Authorization and Security?
Yes — a 51-card Authentication, Authorization and Security deck, printed in full in the flashcards section of this page and available in the Examius app with spaced repetition. The free plan covers one exam of your choice, including its flashcards; Examius Pro, a one-time purchase, unlocks every other exam and deck.