Authentication = Who

Authentication is verifying a user is who they say they are. This involves the user having a secret or credential of some kind and supplying that to the server and having the server verify that secret

Authorization = What

Authorization is what Role or Permissions the user has.

• password - usually entered directly by the user
• token - Like a password but generated by the server and stored on the client so that the client can continue to make requests on the user's behalf. Examples of this include OAUTH tokens and JWT Tokens.
• session id - Similar to a token, this is used by the browser to keep track of a user's session with the server, thus verifying that the user is the correct user. (This isn't enough on it's own to authenticate, you must use a token or password first). But it still should be protected just like a password or token.
• two factor authentication code - A code a user enters in addition to their password, can be sent via SMS, Email or generated by some software on the user's device

A single private key is used to encrypt some data using a lossless algorithm. You can use the private key to decrypt and restore the original data

Lossless compression is a class of data compression algorithms that allows the original data to be perfectly reconstructed from the compressed data. Lossless data compression is used in many applications. ... For example, it is used in the ZIP file format and in the GNU tool gzip.

A system with two keys, a private key and a public key. If Bob wants to send an encrypted message to Alice then Bob uses his private key and Alice's public key to encrypt the message. Now not even Bob can decrypt the message. The only way to decrypt the message is for Alice to use her private key and Bob's public key

Symmetric Encryption - Using a single private key to encrypt some data using a lossless algorithm. You use the private key to decrypt and restore the original data.

Asymmetric Encryption - A system with two keys, a private key and a public key.

The hash function has either been solved, or has been shown to have a flaw

MD5 and SHA-1 should not be used to store user passwords.

Hash functions are algorithms that generate a lossy hash of a value such that the original value cannot be recovered if someone has the hash

A Salt is a random value added to a password before hashing and stored alongside the password in the database. This makes rainbow tables of pre-computed hashes less useful for figuring out the original password.

1. PBKDF2
2. bcrypt
3. Argon2

This is just where you try to hash every possible combination of characters until you get a matching hash. This is slow.

You use a list of pre-computed hashes (A Rainbow Table) and compare the hash you want to crack against it. This is still slow, but faster than the brute force attack.

Session based authentication is where you use a session-id, stored in a cookie, to authenticate the user once they have first authenticated with a password.

npm install express-session

    app.use(session({
        secret: 'a5d63fc5-17a5-459c-b3ba-6d81792158fc', // Secret used to verify the session-id
        resave: false, // Recommended by the express-session package
        saveUninitialized: false, // Recommended by the express-session package
    }));

Typically it should be stored in an environment variable in your .env file.

By default, express-session stores the session data in memory. Which means if you restart your express server you are going to lose your session data (all users will suddenly be logged out of the system).

The middleware creates a .session property on the express req (Request) object. You can use this to store information you would like to persist for the user, such as the user's id or other information that is relevant for your application

If you store your express-session in memory (the default method), if your server is restarted the session data will be lost and all of your users will suddenly be logged out of the system.

Configure a different mechanism for the session store.

We can use the connect-pg-simple module to connect to postgreSQL and store the session in a table in our database

    const store = require('connect-pg-simple');
    app.use(session({
        store: new (store(session))(),
        secret: 'a5d63fc5-17a5-459c-b3ba-6d81792158fc',
        resave: false,
        saveUninitialized: false,}));

It will need an environment variable named DATABASE_URL to know which postgreSQL database to conneect to.

bcrypt: npm install bcryptjs

const hashedPassword = await bcrypt.hash(password, 10);

const passwordMatch = await bcrypt.compare(password, user.hashedPassword.toString());

The passwordMatch value will be a boolean.

• httpOnly: Makes the cookie only be able to read and written by the browser and NOT by JavaScript.
• secure: The browser will only send this cookie if the connection is HTTPS.
• domain: If this isn't set it will assume the cookie should be the same as the site's domain.
• expires: The date and time when the cookie expires.
• maxAge: The number of milliseconds before the cookie expires (usually easier to use than expires)
• path: Defaults to '/ but it's a prefix for the path in the URL that the cookie is valid for (seldom used)

Representational State Transfer

• RESTful APIs have URI's which are nouns: /tweets/12 and the HTTP methods are verbs
• GET
• POST
• PUT
• PATCH
• DELETE
• With RPC based APIs you are calling functions: getTweetById?id=12

Collection resources would return a collection of items. It would look like: /tweets

A single resource simply returns a single item. /tweets/17

These would return JSON

These would return HTML

No! It is a common way to organize interactions

The reason we call it 'RESTful is because it is more of an idea or a set of guidelines for building APIs which conform nicely with how the web already works

Recall that a stateful operation is the one whose result depends on any state that might change during the execution of the pipeline. Stateless operations retain no state during the execution of the pipeline

There is no necessary session between the client and the server. Data received from the server can be used by the client independently. This allows you to have short discrete operations. This is a natural fit for HTTP operations in which requests are intended to be independent and short-lived.

Use express.json() middleware to parse the HTTP request bodies with type application/json

Create a new POJO containing only the information needed

    app.get('/users/:id', asyncHandler(async (req, res) => {
        const user = await User.findByPk(req.params.id);
        //A new POJO containing only user.id and user.email
        const userData = {
            id: user.id,
            email: user.email
        }
        res.json(userData);
    }));

You might use the map function to map out an array of objects. Take, for instance, the users object representing the return from the User.all() call may look as follows:

[
  {
    id: 1,
    email: 'mary@marylark.com',
    name: 'Mary',
    password: 'mypassword'
  },
  {
    id: 2,
    email: 'kyle@kylelark.com',
    name: 'Kyle',
    password: 'kylespassword'
  }
]

    app.get('/users', asyncHandler(async (req, res) => {
        const users = await User.all();
        //A new array of POJOs containing only the user.id and user.email fields
        const usersData = users.map(user => {
            return { id: user.id, email: user.email }
        });
        res.json(usersData);
        }));

usersData then looks as follows. Notice we are not returning the sensitive password information:

[
  { id: 1, email: 'mary@marylark.com' },
  { id: 2, email: 'kyle@kylelark.com' }
]

Cross-Origin Resource Sharing. By default, JavaScript running in the browser can only access API resources from the same origin (i.e. domain, protocol, port). Cross Origin resource sharing is when you attempt to access another domain, protocol, or port that is not the same as your origin.

YES! Even the ports must be the same, if the default settings are used when executing your JavaScript.

1. Install the cors package: npm install cors
2. Use the cors middleware package: app.use(cors({ origin: "http://localhost:3000"}))

You probably wnat to store the CORS origin in an environment variable in your .env file instead of hard coding it.

OAuth 2.0 is a standardized mechanism for authenticating users using a 3rd party OAuth provider.

1. Your application requests authorization from the person
2. The person informs the authorization server that they want to issue an authorization grant for your application
3. The application uses the authorization grant with its secret information to request an access token
4. The authorization server returns an access token
5. Your application uses the access token to gain access to the user's data from the service API
6. The service API returns the resource that the token allows access to

A json web token.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

1. Encrypted: Provides secrecy between parties. (we won't focus on those). Encrypted tokens hides the integrity of the claims contained within it from other parties.
2. Signed: Signed tokens can verify the integrity of the claims contained within it.

1. header: Contains basic info about the JWT such as the typ (type) and alg algorithm.
2. payload: Contains any extra info you would like to store inside the JWT
3. signature: A digital signature created using a hashing algorithm used to verify that the payload hasn't been tampered with. It also verifies the origin of the JWT.

The JWT token consist of a single string with these three parts separated by the . character. Each part of the token is Base64 encoded.

authentication and authorization

No

JSON Web Tokens are a good way of securely transmitting information between parites. Because JWTs can be signed -- for example, using public/private key pairs -- you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

A JWT Header. It typically consists of two parts - the type of the token, which is JWT, and the signing algorithm being used, such as HMAC, SHA256, or RSA.

A JWT Payload

Payloads are the second part of a JWT token. The payload contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are tree types of claims: registered, public, and private claims.

• Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are:
  • iss (issuer)
  • exp (expiration time)
  • sub (subject)
  • aud (audience)
  • there are others ...
• Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
• Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.

This is the signature of a JWT. To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

jwt.io

A JWT that has the header and payloaded encoded, and is signed with a secret. Note that each part is separated by a .