Security & Access Control
Security an analyst must specify — OAuth2 grants, JWT structure and revocation, mTLS, TLS/HTTPS, symmetric vs asymmetric encryption, hashing, digital signatures, and token auth across microservices.
14 questions
JuniorTheoryVery commonWhat is hashing, how does it differ from encryption, and why does a password need a salt?
What is hashing, how does it differ from encryption, and why does a password need a salt?
Hashing is one-way and cannot be reversed. Encryption is two-way — a key recovers the plaintext. Passwords are hashed, not encrypted, so a breach is useless. A salt is unique per password, so equal passwords hash differently and beat rainbow tables.
Common mistakes
- ✗Calling hashing a reversible operation with a hidden key
- ✗Storing passwords encrypted rather than salted and hashed
- ✗Using one shared salt instead of a unique salt per password
Follow-up questions
- →Why is a fast general-purpose hash a poor choice for passwords?
- →What does a pepper add on top of a per-password salt?
JuniorTheoryVery commonWhat is the difference between HTTP and HTTPS, and what does TLS guarantee?
What is the difference between HTTP and HTTPS, and what does TLS guarantee?
HTTP sends requests in plaintext anyone can read or alter. HTTPS is HTTP wrapped in TLS, adding confidentiality, integrity, and server authenticity — the certificate proves you reached the real host. TLS does not hide that a connection happened.
Common mistakes
- ✗Thinking HTTPS hides that a connection happened or to which host
- ✗Assuming TLS is only about encryption and forgetting integrity
- ✗Believing the certificate authenticates the user, not the server
Follow-up questions
- →What does the certificate authority actually vouch for in a certificate?
- →Why is encryption alone not enough without an integrity check?
JuniorTheoryCommonHow do identification, authentication and authorization differ?
How do identification, authentication and authorization differ?
Identification claims who you are. Authentication proves that claim with a password, token, or certificate. Authorization decides what the proven identity may do — which actions and data it may reach. Each is a separate check, in that order.
Common mistakes
- ✗Treating authentication and authorization as one and the same step
- ✗Reversing the order and authorizing before the identity is proven
- ✗Calling the login itself proof of identity rather than a mere claim
Follow-up questions
- →Where does multi-factor authentication fit into these three steps?
- →Can a request be authenticated yet still fail authorization?
MiddleTheoryCommonWhat is a digital signature, and how does it differ from encryption?
What is a digital signature, and how does it differ from encryption?
A digital signature is a hash signed with the private key, verified with the public one. It proves integrity and authenticity but hides nothing; encryption instead conceals content. Sign with the private key; encrypt with the recipient's public key.
Common mistakes
- ✗Thinking a signature encrypts or hides the message content
- ✗Signing with the public key instead of the private key
- ✗Believing a signature provides confidentiality, not integrity
Follow-up questions
- →How does a certificate authority use a signature to vouch for a key?
- →Can you both sign and encrypt one message, and in which order?
MiddleTheoryCommonWhat is a JWT, which three parts does it have, and what must never go in the payload?
What is a JWT, which three parts does it have, and what must never go in the payload?
A JWT is a signed token in three parts: header, payload, and signature. The signature proves integrity and origin but does not encrypt — anyone can read the payload. So never put secrets, passwords, or personal data in it, and keep it short-lived.
Common mistakes
- ✗Believing the payload is encrypted rather than merely signed
- ✗Putting secrets or personal data into a readable payload
- ✗Trusting the header alg field and allowing an alg of none
Follow-up questions
- →How does the server verify a JWT it did not store anywhere?
- →Why keep JWT expiry short if you cannot easily revoke one?
MiddleTheoryCommonWhat is mTLS, and when do you require it between microservices?
What is mTLS, and when do you require it between microservices?
mTLS is mutual TLS — both sides present certificates, so each authenticates the other, not just the server as in plain TLS. Require it between services in a zero-trust network, where every service must prove its identity and the network is untrusted.
Common mistakes
- ✗Thinking only the server presents a certificate under mTLS
- ✗Calling mTLS a double layer of TLS rather than mutual auth
- ✗Requiring mTLS for browser traffic rather than service-to-service
Follow-up questions
- →Who issues and rotates the service certificates in an mTLS mesh?
- →How does mTLS relate to a zero-trust network model?
MiddleTheoryCommonWhat is OAuth 2.0, which roles does it define, and what is the authorization-code flow?
What is OAuth 2.0, which roles does it define, and what is the authorization-code flow?
OAuth 2.0 lets a user delegate access without sharing a password. Its roles are resource owner, client, authorization server, and resource server. The code flow logs the user in, returns a code the client swaps server-side for an access token.
Common mistakes
- ✗Calling OAuth 2.0 authentication and sharing the user's password
- ✗Thinking the access token comes back in the first redirect
- ✗Confusing the authorization code with the access token itself
Follow-up questions
- →Why is the PKCE extension added to the code flow for public clients?
- →What is the difference between an access token and a refresh token?
MiddleTheoryCommonWhat is RBAC, what is ABAC, and when does RBAC stop scaling?
What is RBAC, what is ABAC, and when does RBAC stop scaling?
RBAC grants permissions through roles a user is assigned. ABAC decides per request from attributes — user, resource, action, context. RBAC stops scaling when fine-grained contextual rules force a role explosion; ABAC solves it at higher policy cost.
Common mistakes
- ✗Swapping the definitions of RBAC and ABAC
- ✗Claiming RBAC never suffers a role explosion at scale
- ✗Thinking ABAC needs no policy and is always simpler
Follow-up questions
- →How do RBAC and ABAC combine in a real production system?
- →What is a role explosion, and what actually triggers it?
MiddleTheoryCommonHow do symmetric and asymmetric encryption differ, and where is each used in TLS?
How do symmetric and asymmetric encryption differ, and where is each used in TLS?
Symmetric uses one shared key for both directions — fast, but the key must be delivered safely. Asymmetric uses a public/private pair — slower, no shared secret. TLS uses asymmetric in the handshake to agree a key, then symmetric for bulk data.
Common mistakes
- ✗Swapping which of the two uses a shared key versus a key pair
- ✗Thinking TLS uses asymmetric crypto for the bulk data
- ✗Assuming a symmetric key can travel over plaintext safely
Follow-up questions
- →Why not use asymmetric encryption for the whole session?
- →How does the symmetric session key get agreed without leaking it?
MiddleTheoryCommonDescribe the TLS handshake at the depth an analyst needs — what is exchanged and what is the certificate for?
Describe the TLS handshake at the depth an analyst needs — what is exchanged and what is the certificate for?
The sides pick a cipher, the server sends its certificate, and the client validates it against a trusted CA. They then agree a symmetric session key via asymmetric crypto. The certificate binds a hostname to a public key, proving the host is real.
Common mistakes
- ✗Thinking the session key is sent in plaintext during the handshake
- ✗Believing the certificate authenticates the user, not the server
- ✗Assuming asymmetric crypto encrypts the whole session, not just setup
Follow-up questions
- →Why switch to a symmetric key after the asymmetric setup?
- →What breaks if the certificate chain does not reach a trusted CA?
MiddleTheoryCommonHow do API key, Basic auth, Bearer token and OAuth differ, and which for a partner integration?
How do API key, Basic auth, Bearer token and OAuth differ, and which for a partner integration?
An API key is a static secret naming a caller — simple, coarse. Basic auth sends username and password each call. A Bearer token is issued, expiring. OAuth grants scoped, revocable tokens. For a partner, prefer OAuth or a scoped API key over Basic.
Common mistakes
- ✗Calling Basic auth a secure choice for a partner integration
- ✗Treating API key, Bearer, and OAuth as interchangeable
- ✗Thinking a Bearer token is the user's raw password
Follow-up questions
- →Why is a scoped, revocable credential safer for a third party?
- →How do you rotate a partner's API key without downtime?
MiddleTheoryCommonHow does a token travel across a chain of microservices — propagation, exchange, or a service-to-service token?
How does a token travel across a chain of microservices — propagation, exchange, or a service-to-service token?
Propagation forwards the user's token unchanged, so every hop holds full user scope. Token exchange swaps it each hop for a narrower token. A service-to-service token authenticates the calling service, not the user. Systems often combine both.
Common mistakes
- ✗Thinking a propagated token narrows its own scope automatically
- ✗Confusing a service-to-service token with the user's token
- ✗Believing token exchange widens rather than narrows the scope
Follow-up questions
- →Why is forwarding the user's full-scope token down the chain risky?
- →When do you need a service identity separate from the user's?
SeniorTheoryOccasionalA JWT is stolen and stays valid for 30 minutes. What can you actually do, and how do you design revocation?
A JWT is stolen and stays valid for 30 minutes. What can you actually do, and how do you design revocation?
A JWT is self-validating, so it cannot be un-issued server-side. Keep expiry short with refresh tokens, and add a revocation check — a denylist or per-user token version checked each call. It trades statelessness for a lookup but kills it early.
Common mistakes
- ✗Assuming a stateless JWT can be deleted server-side to revoke it
- ✗Thinking nothing at all can be done short of waiting for expiry
- ✗Believing a short expiry alone revokes an already-stolen token
Follow-up questions
- →How do refresh tokens limit the damage from a leaked access token?
- →What does adding a denylist cost you in latency and stored state?
SeniorDesignOccasionalDesign authentication and authorization for one backend serving three clients: a native mobile app, a browser single-page web app, and a partner server-to-server API. Their trust and session needs differ — the mobile app stays logged in for weeks, the web app runs in a browser exposed to XSS and CSRF, and the partner is another company's server with no human present. Specify how each client authenticates, what credential or token each receives, how long sessions live and how they are refreshed and revoked, and which authorization checks the backend applies so one compromised client cannot exceed its own scope. Note the main trade-offs.
Design authentication and authorization for one backend serving three clients: a native mobile app, a browser single-page web app, and a partner server-to-server API. Their trust and session needs differ — the mobile app stays logged in for weeks, the web app runs in a browser exposed to XSS and CSRF, and the partner is another company's server with no human present. Specify how each client authenticates, what credential or token each receives, how long sessions live and how they are refreshed and revoked, and which authorization checks the backend applies so one compromised client cannot exceed its own scope. Note the main trade-offs.
OAuth 2.0, a grant per client. Mobile: PKCE code flow, short token, refresh in secure storage. SPA: token in memory, refresh in httpOnly cookie. Partner: client-credentials, no user. Backend validates tokens and enforces revocable per-client scopes.
Common mistakes
- ✗Giving the browser SPA a long-lived token in localStorage
- ✗Reusing one shared credential or scope across all three clients
- ✗Letting the machine partner ride a human user's identity
Follow-up questions
- →Why is PKCE important for the mobile and SPA public clients?
- →How would you revoke only the partner's access without touching users?
