Forem: Aneesh Arora

Take the pain to learn user authentication before you use an external provider

Aneesh Arora — Tue, 19 Mar 2024 09:01:37 +0000

External user authentication is not as simple, secure and cheap as it seems. These are the lessons I learned while implementing user authentication and authorization for my startup Afterword.

Most startups nowadays rely on external user authentication services called "Identity as a Service" (IDaaS) or "Authentication as a Service" (AuthaaS). Even big companies like OpenAI use auth0. Firebase by Google is also really popular. While I guess it makes sense in the world of “move fast and break things” we have been sold a lot of lies about user authentication by these providers which I would like to dispel.

Developers think outsourcing user authentication to an external provider is easier, more secure, cheaper in the short run but it’s not true. If you don’t understand security well enough you will still store important information like user authentication tokens in localstorage or cookies that can be read by client side javascript. Javascript injection attacks will allow hackers to steal user credentials and pretend to be them, exposing user data and consuming their credits in a Saas application.

Problems with external user authentication services

The False Security of Outsourcing: Outsourcing user authentication does not automatically ensure security; poor implementation can leave users exposed.
Privacy Concerns with Third-Party Data Handling: Utilizing third-party authentication involves entrusting user login data to another vendor, risking user privacy and data exploitation by competitors.
Control Over User Authentication Flow: Third-party services limit customization and control the flow of user authentication, degrading user experience due to external redirections.
Design Constraints with Pre-Designed UI: Pre-designed user interfaces from third-party services may not align with your site's aesthetics, causing a disjointed experience.
Tech Stack Compatibility Issues: Third-party user authentication may not seamlessly integrate with your specific tech stack.
Time Efficiency in Self-Implementation: Self-implementation of user authentication can be quicker with proper understanding; my experience saw more than a week for third-party setup versus 4-5 days for in-house.
- Cost of Third-Party Authentication
- Hosted Services: Costs escalate with user growth.
- Self-Hosting: Adds complexity when deploying and contributes to extra costs also.
Costs of Advanced Features: Extra features like social login and multi-factor authentication in external services incur additional expenses.
The Risks of Vendor Lock-In: Dependence on third-party providers exposes you to their changing terms, costs, and risks of vendor lock-in.
Challenges in Transitioning to In-House Solutions: Shifting to an in-house system later can be complex, often necessitating password changes for users, thus increasing friction and dissatisfaction.

The basics of user authentication and authorization

User authentication and authorization may initially appear challenging and intimidating, but this perception changes once you grasp the underlying mechanisms. Moreover, it's an essential aspect you can't bypass. Despite popular belief, third-party user authentication isn't the panacea it's often made out to be.

In the sections below, I'll guide you through a secure method for implementing user authentication and authorization. While there are other approaches, they fall beyond the scope of this blog post.

First let’s understand the difference between user authentication and user authorization:

User Authentication: Process of verifying identity of the user. Typically done using username and password.
User Authorization: Verifying the logged in user when they make a certain request like accessing their saved data or performing any action that the user should be signed in for.

Upon successful user authentication, that is, when they log in, the server issues a cookie containing a token(a unique string). This cookie is sent by the browser with each subsequent request, allowing the server to verify the user's identity and respond to their requests.

There are two primary methods to verify this token:

Database Storage: Store the token and its corresponding user ID (a unique identifier in the database akin to a primary key) in the database.
JSON Web Token (JWT): Utilize JWT, a widely supported standard that I will explain below.

How JSON Web Token works

Many libraries support JWT so you don’t have to implement it yourself but you do need to understand it. One good one for python is PyJWT.
pip install PyJWT

JWTs are advantageous as they encapsulate user details, such as the user ID, along with other pertinent information chosen by the developer. This data is encrypted using a secret key and stored in the cookie. When the user makes a request, the server decrypts the JWT to identify the user and access their data.

Benefits of using JWT include:

Speed: Eliminates the need for additional database queries to fetch the user ID.
Built-in Expiration: JWTs have an inherent expiry time, enhancing security by limiting the window during which a compromised token could be used.

At Afterword, for instance, access tokens expire after one hour for added user safety.

Example code to create and decode JWT in python using PyJWT:

import jwt
from jwt import PyJWTError
from datetime import datetime, timedelta

SECRET_KEY = "Generate a secret key and put it here"
ALGORITHM = "HS256"
TOKEN_EXPIRE_MINUTES = 60

def create_jwt(data: dict):
    to_encode = data.copy()
    expire = datetime.utcnow() + timedelta(minutes=TOKEN_EXPIRE_MINUTES)
    to_encode.update({"exp": expire}) 
    encoded_jwt = jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
    return encoded_jwt

# Verify JWT token
def decode_token(token):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        return payload

    except PyJWTError:
        raise Exception(status_code=401, detail="Could not validate credentials")

create_jwt({"user_id":user_id}) #you can also put other user data in this dict as key value pairs

To address the issue of token expiration and avoid frequent re-logins, which could detract from user experience, we employ a dual-token approach:

Access Token: Short-lived, used for regular authentication.
Refresh Token: Longer-lived, used to request new access tokens.

The refresh token is only sent to the server when an access token is rejected, not with every request. This strategy minimizes the risk of a refresh token being compromised. For heightened security, the refresh token can be stored in the database and validated against it. Upon user logout, or to prevent misuse, refresh tokens can be either deleted or added to a blacklist, ensuring that outdated, yet valid, tokens cannot be used to gain unauthorized access.

Storing JWTs (access and refresh tokens) browser side

Since local storage and other storage methods like IndexedDB can be accessed by javascript running in the browser they are not a safe place to store user authorization credentials. Hackers can exploit it using Cross-Site Scripting (XSS) to inject malicious code and access these tokens.

An alternative to this is the use of cookies. While regular cookies can be accessed by JavaScript, HTTP-only cookies are more secure as they are accessible only to the server. The browser is designed to prevent any JavaScript from reading HTTP-only cookies. Moreover, cookies set by the server should be flagged as 'Secure' to ensure they are transmitted exclusively over HTTPS connections, not unsecured HTTP.

Another critical attribute of cookies for security is the 'SameSite' flag. Setting this flag to either 'Strict' or 'Lax', instead of 'None', significantly enhances security. This configuration helps prevent the browser from sending the user's cookies in response to Cross-Site Request Forgery (CSRF) attacks. When combined with the HTTP-only and Secure flags, setting SameSite to 'Strict' provides robust protection by safeguarding against XSS, CSRF, and ensuring that all data is transmitted securely over HTTPS.

For additional layers of security, the implementation of CSRF tokens can be considered.

Example of setting a secure, HTTP-only and SameSite="Strict" using a fastapi server:

from fastapi import FastAPI, Response, Form
from typing import Annotated
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()

# Set up CORS middleware
app.add_middleware(
    CORSMiddleware,
    allow_origins=[FRONTEND_URL],
    allow_credentials=True,
    allow_methods=["*"],  # Allows all methods
    allow_headers=["*"],  # Allows all headers
)

TOKEN_EXPIRE_MINUTES = 60

@app.post("/login")
async def login(email: Annotated[str, Form()], password: Annotated[str, Form()], response: Response):
    user = #Retrieve user from database using email
    if user and password == user["password"]: #Don't store password in plain text in a real application
        response.set_cookie("token", value=JWT_token, max_age=TOKEN_EXPIRE_MINUTES*60, httponly=True, secure=True, samesite="Strict", domain="your site domain")
        return True
    else:
        return False

This provides a solid foundation in understanding the user authentication and authorization flow, valuable knowledge regardless of whether you opt for an external provider. To develop a fully in-house user authentication and authorization system, more in-depth information is required. Stay tuned for the second part of this blog post, where I'll delve into password encryption and the intricacies of sending emails.

Why we use Server Sent Events and how to implement them in FastAPI

Aneesh Arora — Wed, 10 Jan 2024 04:33:42 +0000

I, Aneesh Arora, am the cofounder and CTO of Afterword and have written this post to describe the advantages of using Server Sent Events for generative AI applications and how to implement them using FastAPI.

When it came to implementing SEE using FastAPI back in July 2022 I could find only two articles on the internet and neither of them were very helpful. There might be more articles today but all of them fail to explain certain basic concepts clearly. Hence I am attempting to mitigate that gap.

You can also read this on our website.

Challenges in AI Model Integration

Speed and Content Limitation: When building an application with AI models, a key challenge is the speed of content creation and the limit on the amount of content that can be processed at once.

Enhancing User Experience in Afterword

Dual Tasks: Afterword must scrape web articles and condense their content, both time-consuming tasks.
Managing User Expectations: Users expect quick results. It's vital to:
- Provide partial summaries during processing.
- Update users on the process status.
Purpose: This ensures users know the application is active and not stalled.

Technical Solutions for Timely Updates

WebSockets vs. Server-Sent Events (SSE):
- WebSockets: Used in bidirectional communication (e.g., WhatsApp), but resource-intensive.
- Server-Sent Events (SSE): Offers a unidirectional communication path.
  - Server broadcasts updates.
  - Client receives updates passively, different from traditional HTTP requests where client has to make a new request for every update.

Why Choose SSE?

Efficient Broadcasting: Chosen for its efficiency in broadcasting updates.
Industry Validation: Similar approach used by OpenAI for ChatGPT.
Early Adoption: We implemented SSE in July 2022, predating ChatGPT's launch.

Implementing SSE in Afterword

Having settled on Server-Sent Events (SSE) for Afterword, our next step was to implement it practically. For Afterword's backend, we chose FastAPI, a leading Python framework, aligning with our decision to use Python for our AI functionalities. I'll delve into Afterword's complete tech stack in a subsequent, more detailed blog post.

SSE implementation involves two main components: the server and the client. On the server side, we needed to integrate SSE within the FastAPI framework. Regarding the client side, the implementation of SSE in JavaScript will be the same no matter which frontend framework you choose to work with unless you use HTMX (the frontend framework for javascript haters. Just kidding, it’s really cool do check it out).

FastAPI, built upon the Starlette framework, can leverage a third-party library specifically designed for Server-Sent Events (SSE), namely sse-starlette. Implementing SSE in FastAPI using this library is straightforward. Instead of returning a typical response from a FastAPI route, you use EventSourceResponse(generator_function()).

To understand this better, let's clarify what a generator function is. In Python, a generator function is used to return a sequence of values over time, each time it's iterated, by employing the yield statement. This differs from a normal function, which returns a single value using the return statement.

For instance, a standard function is structured as follows:

def normal_function():
    #Perform some action
    return final_value

In contrast, a generator function looks like this:

def generator_function():
    #Perform some action
    yield first_value
    #Perform more action
    yield second_value
    #Perform even more action
    yield final_value

Each yield in the generator function produces a value that can be sent to the client as part of an SSE stream. This allows for real-time data transmission to the client, making it an ideal approach for applications that require continuous data updates, like Afterword.

Standard vs SSE route

In FastAPI, a standard route for a simple request-response cycle looks quite straightforward. Here's an example of such a route:

@app.get("/normal")
def hello_world():
    return {"Hello": "World"}

This route responds with a simple JSON object upon a GET request.

However, for a route that implements Server-Sent Events (SSE), the structure changes to accommodate the SSE pattern. This is achieved by returning an EventSourceResponse with a generator function. Here's how the SSE route would look:

@app.get("/SSE")
def server_sent_events():
    return EventSourceResponse(generator_function())

With the generator function you've described, this SSE route will send three separate updates to the client (browser) before ceasing transmission. Each yield in your generator function corresponds to a separate update sent to the client.

Message format for SSE

When using SSE, it's crucial that the messages sent to the browser adhere to the structure specified in the HTML format. Each message consists of various fields, each on a new line, defined as fieldname: value. The key fields include:

event: Specifies the event type. If this is set, it triggers a browser event for which listeners can be added using addEventListener(). If not set, the onmessage handler is used.
data: Sets the event ID.
id: Contains the actual message data.
retry: Defines the reconnection time in milliseconds, instructing the browser how long to wait before attempting to reconnect if the connection is lost.

All other field names are ignored by the browser.

Events are optional but they are helpful. For example by setting an event name - “end” we can tell the browser when to stop listening for more messages. Of course the same can be achieved based on certain input received through the data field as well.

In your generator function, the messages are structured to include these key fields. For instance:

def generator_function():
    yield {
        "event": "event_name",
        "id": event_id, #any unique id
        "retry": 15000, #15s
        "data": json.dumps({"message": "message text"}) #actual data being sent
    }

Now the reason we use json.dumps is because Python data structures cannot be directly sent over a network. json.dumps serializes these structures into a string representation, which can be transmitted over the network.

Handling SSE in browser using javascript

Receiving Server-Sent Events (SSE) in the browser using JavaScript is relatively straightforward and involves setting up an EventSource object to listen for messages from the server. Here's a breakdown of how it works based on your provided code:

1. Initialize the EventSource:

const evtSource = new EventSource(URL);

This line creates a new EventSource instance, connecting to the specified URL (where your FastAPI server sends SSE).

2. Listen for Specific Events:

evtSource.addEventListener("event_name", function(event) {
    let data = JSON.parse(event.data);
    // Use the data
});

Here, you're adding an event listener for a specific event type, "event_name". When the event is received, the callback function is executed. The event data, which is a JSON string, is parsed back into a JavaScript object.

3. Listen for a Termination Event:

evtSource.addEventListener("end", function(event) {
    evtSource.close();
});

This listener waits for an "end" event, signaling that no more messages will be sent. Upon receiving this event, it closes the EventSource connection.

4. Error Handling:

evtSource.onerror = function(event) {
    // Handle error
};

This function will be called if an error occurs with the EventSource connection. You can implement specific error handling logic here.

This setup ensures that your browser client is continuously listening for messages sent from your FastAPI server via SSE. It processes each message as it arrives and responds accordingly, whether that's updating the UI, triggering further actions, or closing the connection. This method is efficient for real-time applications, as it reduces the need for repeated polling and provides a more interactive user experience.

Complete working example

Now that we know how to send and receive SSE let us look at a full example.

In this we will assume that we are looping over an array and generating data and sending to the browser.

1. Install all dependencies:

pip install fastapi
pip install uvicorn[standard]
pip install sse-starlette

2. Create a python file 'sse.py' and copy the below code to it:

from fastapi import FastAPI
from sse_starlette.sse import EventSourceResponse
import time
import json
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()

# Set up CORS middleware
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],  # Allows all origins
    allow_credentials=True,
    allow_methods=["*"],  # Allows all methods
    allow_headers=["*"],  # Allows all headers
)

@app.get("/SSE")
async def SSE():
    return EventSourceResponse(generator_function())

RETRY_TIMEOUT = 15000 #15s

async def generator_function():
    #We are sleeping to simulate CPU processing
    time.sleep(2) #sleep for 2 seconds
    yield {"event": "message","id": 1,"retry": RETRY_TIMEOUT,"data": json.dumps({"message":"1st SSE"})}
    time.sleep(1)
    yield {"event": "message","id": 2,"retry": RETRY_TIMEOUT,"data": json.dumps({"message":"2nd SSE"})}
    #Loop over a list and send SSE
    messages = ["data 1","data 2","data 3"]
    for message in messages:
        time.sleep(1)
        yield {"event": "message","id": 3,"retry": RETRY_TIMEOUT,"data": json.dumps({"message":message})}
    time.sleep(1)
    yield {"event": "end","id": 4,"retry": RETRY_TIMEOUT,"data": json.dumps({"message":"last SSE"})}

3. CORS Middleware Configuration:

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],  # Allows all origins
    allow_credentials=True,
    allow_methods=["*"],  # Allows all methods
    allow_headers=["*"],  # Allows all headers
)

This sets up CORS to allow requests from any origin, which is crucial for API accessibility from different domains. Since we will be making requests using javascript.

4. Start FastAPI server:

uvicorn sse:app

5. Setup a svelte project: You can use any framework you like

npm create svelte@latest sse
cd sse
npm install

6. Overwrite content of sse/src/routes/+page.svelte with the code below:

<script>
let message = "";
async function SSE()
{
  const evtSource = new EventSource("http://localhost:8000/SSE");
  evtSource.addEventListener("message", function(event) {
      let data = JSON.parse(event.data);
      message = data.message;
  });
  evtSource.addEventListener("end", function(event) {
      let data = JSON.parse(event.data);
      message = data.message;
      evtSource.close();
  });
}
</script>
<h1>SSE</h1>
<p><a on:click={SSE} href="#">Click</a> to start SSE</p>
<p>{message}</p>

7. Start svelte server:

npm run dev -- --open

9. Open http://localhost:5173 and click to start SSE: You should be able to see the messages in your browser

Hope you found this post helpful. Do check out Afterword to take control of your reading and tackle information overload.