HTTP Security Basics — My Cheat Sheet

Chuma S. Okoro
3 min readJan 8, 2021

This Doc will discuss different forms of authentication not authorization. Authentication has to do with determining whether a user/device has the right credentials to a secure system(Who are you). Authorization has to do with determining what a user/device should be allowed to do after they have been authenticated(What can you do).

HTTP Basic Authentication

  • Simplest form of auth
  • Stateless so your user/password is required for every api call
  • Credentials are not encrypted when sent and are passed to the server via the header
  • Pros: usually faster requests, easy to code up, large browser support
  • Cons: not very secure at all since there’s no encryption, credentials needed for every request,
Basic auth youtube video that i found

HTTP Digest Authentication

  • Very similar to basic auth except that the password is encrypted using MD5 hash
  • Same header as basic auth
  • Utilizes Nonce tokens to prevent replay attacks
  • Pros: more secure that basic with all of the benefits basic offers
  • Cons: similar cons to basic, vulnerable to “man in the middle” attacks (basically eavesdropping), passwords on server are more vulnerable than in basic since the password being sent to the server is already hashed(more info on this here).
video i found on digest auth

Session Based Authentication

  • user state is stored on the server so credentials not needed on every request
  • server generates a “session” and gives the session id to the browser as a cookie
  • the stored cookie(session_id) is used for subsequent requests instead of credentials
  • stateful
  • Pros: fast subsequent logins/request since you dont need credentials, easy-ish to implement since its supported out of the box
  • Cons: stateful so it doesn’t work well for RESTful services, cookies send with every request even when auth isn’t needed, vulnerable to CSRF attacks
video on session stuff

Token Based Authentication

  • user authenticates with valid credentials and the server returns a signed token
  • token used for subsequent requests instead of re-authentication
  • IE. JWT Token which consists of a header(token type and hashing algo), a payload(has claims which are statements about the subject), and a signature(used to verify msg wasn’t changed)
  • token just needs to be validated on server using signature. Doesn’t need to be saved
  • Pros: stateless since server doesn’t need to store the token, faster since db lookup isn’t required for credentials, nice for microservice arch with multiple services that need auth
  • Cons: the way the client stores token can lead to XSS/CSRF(local storage or cookies respectively) attacks, tokens only expire and can’t be deleted which can lead to attackers misusing it until expiration, refresh tokens need to be set up on expiration
interesting vid on token based auth

One Time Password Auth

  • randomly generated code to authenticate a user
  • usually used in conjunction with another form of auth (2 factor auth)
  • trusted system needs to be used with this(email/phone number/fax lol)
  • time based OTP’s are most common.
  • recommended for highly sensitive data
  • Pros: extra layer of protection when used as 2 factor, stolen passwords don’t have risk of being used on other accounts for a user(since they’re randomly generated by the server and not the user)
  • Cons: OTP agents(Duo, Google Authenticator) are difficult to setup if you lose recovery code, heavily reliant on trusted device where a plethora of issues can occur
otp algo

OAuth/OAuth2

  • AUTHORIZATION PROTOCOL. THIS IS NOT AUTHENTICATION!
oauth video if you’re interested

If you found this document useful please like it and subscribe :)

--

--

Chuma S. Okoro

Sr. Software Engineer @ Bloomberg. I love talking about technology and business. Every article has my opinion backed by my experience, education, and research.