# Authenticate and Authroize - JWT token vs Cookies
::: info
講師：Maxx
時間：2024.04.24
地點：C209
[上課簡報傳送門](https://docs.google.com/presentation/d/1PZjKJzSU64RY1h918Iu1vxTjPqet1OQRn8oLPIINFJw/edit?usp=sharing)
:::

### Reminder that this is an *EMI COURSE*

Content

- Authorization
- Cookies
- JWTs
- Applications
- Conclusions

### Authentication vs Authorization

Authentication
: is defined as verifying the user or process

More realistically, it sees if the user is who they say they are and gives a challenge for this verification

Ex. Keycards, emails, Auth apps, etc.

Authorization
: is defined as giving official permissions

More realistically, it determines what the user can access and to what resources

Ex. Keycards, Moodle, etc.

In short, Authentification its the process of verifying the user while Authorization is verifying what the user has access to

## Cookies

Types:

1. Persistent
2. Third-Party Cookies
3. Session Cookies

Emphasis on the 3rd type, which are deleted as soon as the browser closes

Session cookies are about the current session data and should not contain passwords or PID

Cookies work on HTTP,


which means HTTP is stateless and that,

- by default it shouldn't know who you are
- but also provides worst browsing experience [it doesn't remember your preferences!]
- thus we use session cookies

The reason being is that:

- It creates a stateful session
- providing Authentification and Authorization
- Better user experiences

They are:

- Encoded in B64
- Encrypted in AES
- Signed in HMAC
- Hashed in SHA
- or can be in plaintext



# Json Web Tokens

- Open Standard (RFC 7519)
- URL-safe claim exchange
- Compact & self contained
- Digitally signed

Why use JWT?

- More secure
- signed by default

- Stateless
- self-contained
- No db / cache

- Easy to scale

# Safety & Comparison

- Both are vulnerable to Man-in-the-Middle, XSS, CSRF

Cookies

- Cookies are more vulnerable to cookie poisoning or cookie hijacking

Caused by:

- Sensitive info is in the cookie if it is in plaintext or if the backend does not verify

Which could be prevented by:

- Should be prevented by proper verification, not storing PID, enforcing SSL, and employing multi-factor auth

JWTs

- Weak to key leakage/brute force
- Modifying the token's payload or header
- Improper token validation

Causes:

- using weak secret
- server validation failure
- improper key management

Which could be prevented by:

- Token signed by secure STRONG algorithm (i.e. RSA, ECDSA, HMAC)
- Proper secret storage
- enforcing token lifetime (setting expiry/revocations)

# Conclusion

The question whether there is a proper time to use one or the other is a trick, it depends on what you need for what you want to build