Understanding OAuth/JWT well means being able to name the specific attack each design decision in this reference is actually defending against — this is exactly the kind of question a security-focused interview reaches for.
CSRF (Cross-Site Request Forgery) against the OAuth callback. Without protection, an attacker could trick a victim's browser into completing an OAuth flow using the attacker's account — silently linking the victim's session to an account the attacker controls, sometimes called login CSRF. The state parameter (sent in step 2 of the Authorization Code flow, and checked for an exact match on the redirect in step 4) defends against this: the client generates a random, unpredictable state value tied to the current browser session before redirecting, and rejects any callback whose state doesn't match — a forged callback the attacker initiates on the victim's behalf won't have the value the victim's own session actually generated.
XSS (Cross-Site Scripting) stealing a token. If an access or refresh token sits in localStorage, any successfully injected script can read and exfiltrate it directly — no special privilege required beyond running JavaScript on the page at all. This is the direct motivation for the httpOnly cookie recommendation in the token storage section above: a cookie flagged httpOnly is invisible to document.cookie and every other JavaScript API, closing this specific exfiltration path even if an XSS vulnerability exists elsewhere on the page.
CSRF against a cookie-authenticated API (the flip side of the httpOnly trade-off). Because a browser attaches cookies automatically to any request to their domain, a malicious page can trigger a state-changing request (a form auto-submitted to yourapp.com/api/delete-account) and the browser will happily attach the real session cookie. Defenses are a SameSite=Lax/Strict cookie attribute (tells the browser not to send the cookie on cross-site requests at all) plus, for stronger protection, an explicit anti-CSRF token the server issues and checks on state-changing requests, which an attacker's page has no way to read or forge.
Authorization code interception/replay. Covered above — the code is short-lived, single-use, and (with PKCE) tied to a verifier only the original client ever possessed, so intercepting the code alone isn't enough to redeem it.
Algorithm confusion / signature-stripping. Covered above — a verifier that trusts the alg the token itself claims can be tricked into treating an RSA-signed token's public key as if it were an HMAC secret. The fix is a verifier that pins the expected algorithm itself.
Open redirect via a malicious redirect_uri. If an authorization server doesn't strictly validate redirect_uri against a pre-registered allowlist, an attacker can register or supply a lookalike redirect target and receive the authorization code intended for the real application. This is why every serious OAuth provider requires redirect_uri values to be registered in advance, and rejects any authorization request whose redirect_uri doesn't exactly match one already on file.