---
title: 'Authentication'
description: 'How authentication works in Open SWE'
---

(in this page, cover how the auth flow works in open swe)

- Discuss how we use GitHub Oauth for client side auth
  - if user is not logged in, it will require them to login
  - if they are logged in, it'll redirect them to the chat page
  - users can update their gh auth via the `/settings` page
- Discuss LangGraph auth
  - all requests made to the LangGraph server are authenticated
  - when making requests from the client, they first go through a proxy route in the Next.js app.
    - proxy route uses the `langgraph-nextjs-api-passthrough` package (https://www.npmjs.com/package/langgraph-nextjs-api-passthrough)
    - this proxy route injects the following headers to the request:
      - `GITHUB_TOKEN_COOKIE` (`"x-github-access-token"`) - this is the user's access token for github. it will allow us to take actions on behalf of the user, such as create gh issues and comments
      - `GITHUB_INSTALLATION_TOKEN_COOKIE` (`"x-github-installation-token"`) - this is the installation token for the github app. it will allow us to take actions on behalf of the github app, such as make commits and open pull requests
      - `GITHUB_INSTALLATION_NAME` (`"x-github-installation-name"`) - this is the name of the installation. will be either your github username if you're making requests against a repo your user owns, or an org name if making requests on a repo in an org
      - all headers are prefixed with `x-` so that they are included in the configurable field of the langgraph runs, so we can access them during a run and not only in the auth middleware
      - all secrets (gh tokens) are encrypted in this proxy route to prevent them being exposed in LangSmith traces, or if other users are somehow able to access your threads/runs.
    - finally, the request is forwarded to your actual langgraph server, where it first runs through an auth middleware to verify the user is authenticated.
  - the first check in the langgraph server auth middleware looks to see if a header is present which would indicate the request is coming from a github webhook
    - if true, it will verify the webhook signature, and authorize it if so. we do not include the user information in this auth step, as that is done in the next request that the webhook handler makes to actually create a new langgraph run based on the webhook event. here is where your gh user is included so that the thread/run created by this webhook is only exposed to you, the user.
  - all requests made to the langgraph server go through this auth middleware. this includes requests to custom routes (like the webhook handler) and requests made to the langgraph server (like creating a new thread/run)
  - if it's not a webhook request, we check for two required headers
    - the installation name
    - the installation token
    - if either are not defined, we throw a 401 unauthorized error
  - after getting these headers, we check to see if there's a github access token (tied to a user)
    - if there is, we use that to verify the user. this would indicate the request was made from the web app
    - if there isn't, we check for two additional headers
      - the user id
      - the user login
      - after getting these values, we verify the user ID & login passed in headers are valid, and that the installation token is valid
      - this occurs when a run is created from a github webhook

    - finally, after validating either the github user id & login, or getting the user ID and login from the user's github access token, we return a new identity object. this contains the user's ID, and the installation name. we use the user ID to ensure the only resources you're allowed to access are your own. the auth middleware then forwards to a handler which runs for each resource type (e.g. create new thread). in this handler we add your user id to metadata if it's a create request, and if it's a get request we verify the user id from the identity matches the one in the metadata.
  - since the access tokens/installation tokens are prefixed with `x-` they're going to be included in the configurable field of the langgraph runs (still encrypted). so whenever we need to take some action (e.g. create new issue) we first extract that field from the configurable field, decrypt, then preform the action.