Auth.md

Auth

Not Web Security...

---

Auth Basics

We check passwords against the records in our database.

Authentication – Is this person who they say they are?

How do people stay logged in?

How do we store information about our client/server relationship?

Bad ideas:

• script variables – won't persist across browser pages
• database documents – we would still need to identify the client each time we wanted to access the DB docs, so we'd need login credentials with EVERY request so we could update our DB docs

Cookies

Small text files sent by default with requests. Key/value pairs.

Created on the server and lives on the client.

With a normal HTTP request, we get a blank slate each time.

With cookies, the server creates a cookie and sends back its response. The client holds onto the cookie. The next time that client makes a request, the cookie comes across with the request.

Sessions

Cookies enable sessions. When a client sends a request the first time:

• we make a session object
• generate an id for that object
• cookie gets session id
• server sends cookie with session id
• client holds onto cookie

For future requests/responses, that client will have a cookie.

XSRF is a big problem with cookies. Cookies aren't necessary for authentication or sessions – you can use tokens instead.

Sessions in Detail

SERVER BACKEND            Express                     CLIENT (BROWSER)
Session store        Session Middleware            Cookie Store for various websites

In our HTTP request, we can see cookies by looking in the header.

If there's no cookie:

• makes a session in our session store
• makes a cookie and attaches it to the request as req.session

The res object then receives the cookie: set-cookie: yourSessionIdHere The res goes through your program as normal.

Client receives the res, renders the response body, then deposits the cookie into the cookie store in the browser.

• The next time the user visits the site, the cookie is attached to the header.
• The req will match the id with sessions in the session store.
• The session may be updated.
• The res does not send a cookie back!

Multiple Sessions

Each cookie id will have an associated session object in the session store.

If we want to automatically log-in a user, we can match the user id connected with the session store's cookie id value.

With that id, we can retrieve our user or other data to let users log in automatically.

OAuth

The 'sign in with google' button we see everywhere is OAuth.

Standard protocol for auth piggybacking. Application: 'consumer' User: 'user' 3rd Party Authority: 'provider'

Consumer (developer) registers dev account with provider.

Provider gives id, secret

1. User makes request to your site (a login)
2. Consumer sends back rendered login page
3. User requests login through provider
4. User gets redirected to the provider
5. User sends alone your CONSUMER ID to the provider with ID in query string
6. Provider renders login page
7. User logs in to provider
8. Provider redirects to Consumer with Auth code
9. Consumer sends my ID and secret along with scope (to get any data from Provider that they need)
10. Provider signs off on client ID, client secret, auth code, and any other data requested by the Consumer
11. Consumer receives auth token
12. Consumer sends response to User (we're good to go!)

The token is just a long string.

Passport

This library handles the interface with Providers.

Passport gives you req.user object to use in your Express routes!

• passport.session() – generates middleware (a function that takes req, res, next)
• serializeUser – if I give you a user, this is what you should store
• deserializeUser – if you have a piece of information, this is how you turn it back into a user
• passport.use – configure a strategy, writing a verification callback for where the user is logging in through
• authenticate – returns middleware: uses strategy, slightly different call in each route

---