Lecture

Contributors: Alicia Wang, Conner Swenberg

In any sort of application involving users, we need a method for verifying identities.

Overview

When making requests to a server, how does the server know who you are and how does the server validate? Authentication is a process by which we ensure and confirm a user's identity.

Example: Upon signing up for an account for some service, they will store your username/email and password credentials (hashed). To later access your account, you login with the same credentials and they check if that same combination exists

Adding new credentials to database upon sign-up

Checking against existing credentials upon log-in

HTTP Basic Authentication

1. Client sends your username and password to server

2. Browser caches (saves) your credentials temporarily

3. Client sends credentials with every request in the header to let the server know your identity

An example of a request from the client with authentication headers:

GET /myfiles/ HTTP/1.1
Host: www.google.com
Authorization: Basic Zm9vOmJhcg==

Zm9vOmJhcg represents a base64 encoding of your username and password and can be decoded to extract your credentials.

Basic authentication has problematic security risks. Your username and password credentials are exposed in every request (even when encoded), so anyone looking at your network traffic would have access to that data. In addition, your credentials are stored until the browser is closed or you clear your cache, so there is no easy way to "log out".

HTTP Session Authentication

Session-based authentication sets up a time period for when a client and server can freely communicate. Sessions are stored as a separate table in the database and are unique to each user. A session object will have (at minimum) a foreign key referencing a user and an expiration datetime.

Authentication Process

1. Client signs in (authenticates) with its credentials

2. Server validates the credentials

3. Server creates and returns a session token for the user

4. Client stores this token as a cookie in the browser or on disk

5. Client sends the token with every request so the server can identify the user

Token Expiration

We design for tokens to expire after a certain length of time. We do this so that any accidental exposure of the token does not have any lasting effects and give someone else permanent permissions. More advanced session authentication schemes involve the ability for a user to easily refresh their session with a second token, called a refresh token. This refresh token is designed to only be used to retrieve a new session token and lasts for a lot longer (potentially on a scale upwards of weeks).

Table Design

CREATE TABLE session (
    id           INTEGER PRIMARY KEY, 
    sessionToken TEXT NOT NULL,
    expiresAt    INTEGER NOT NULL,
    refreshToken TEXT NOT NULL,
    userID       INTEGER NOT NULL,
    FOREIGN KEY (userID) REFERENCES user(ID)
)

Find a user ID associated with a session:

SELECT userId FROM session 
WHERE sessionToken = 
<sessionToken sent in request>

Find a user associated with the user ID:

SELECT * FROM users 
WHERE id = 
<userID from previous query>

Benefits

Requests only contain a session token to prove identity, thus minimizing the exposure of usernames and passwords over requests. By designing these session tokens to expire after a short period of time, we limit potential for accidental access to be granted to unauthorized individuals.