@farmsdotmarket/openauth 0.4.4

package/.changeset/README.md

@@ -0,0 +1,8 @@
+# Changesets
+
+Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
+with multi-package repos, or single-package repos to help you version and publish your code. You can
+find the full documentation for it [in our repository](https://github.com/changesets/changesets)
+
+We have a quick list of common questions to get you started engaging with this project in
+[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md)

package/.changeset/commit.cjs

@@ -0,0 +1,4 @@
+/** @type {import('@changesets/types').CommitFunctions["getAddMessage"]} */
+module.exports.getAddMessage = async (changeset) => {
+  return changeset.summary;
+};

package/.changeset/config.json

@@ -0,0 +1,11 @@
+{
+  "$schema": "https://unpkg.com/@changesets/config@3.0.4/schema.json",
+  "changelog": "@changesets/cli/changelog",
+  "commit": "./commit.cjs",
+  "fixed": [["@farmsdotmarket/openauth"]],
+  "linked": [],
+  "access": "public",
+  "baseBranch": "master",
+  "updateInternalDependencies": "patch",
+  "ignore": ["@openauthjs/example-*"]
+}

package/.changeset/farms-openauth-release-0-4-3-farms-2.md

@@ -0,0 +1,10 @@
+---
+"@farmsdotmarket/openauth": patch
+---
+
+Farms fork maintenance release:
+
+- keep React Native-safe `@openauthjs/openauth/client` export condition
+- keep RN-safe client entrypoint (`authorize`, `exchange`, `refresh`)
+- keep non-Node timing-safe compare path in random utilities
+- keep issuer client URL hardening guardrails

package/.changeset/popular-geese-reply.md

@@ -0,0 +1,5 @@
+---
+"@farmsdotmarket/openauth": patch
+---
+
+update google icon to comply with branding guidelines

package/.changeset/stupid-boats-play.md

@@ -0,0 +1,5 @@
+---
+"@farmsdotmarket/openauth": patch
+---
+
+allow auth style autodetection

package/.changeset/ten-pans-invent.md

@@ -0,0 +1,5 @@
+---
+"@farmsdotmarket/openauth": patch
+---
+
+add linkedin adapter

package/.github/CODE_OF_CONDUCT

@@ -0,0 +1,15 @@
+# Code of Conduct
+
+I don't typically set up a code of conduct for our projects but given this one is security related it will draw a very specific set of problems I want to avoid. There's only two rules
+
+1. Reporting security issues
+
+If you find a security issue please report them to me directly on [X](https://twitter.com/thdxr) or [Bluesky](https://bsky.app/). Do not open a public issue or post publicly in case the issue can be exploited. Feel free to give us a window of time to respond before disclosing it publicly - that seems fair.
+
+2. Reporting "security" issues
+
+A lot of things that seem to fall in that first category are not really security problems, just tradeoffs that were made in the design of OpenAuth. Security products attract a lot of binary opinions like "never use X". We reject this type of thinking entirely - security is a spectrum of usability and infinitely optimizing for "security" does not yield a good product.
+
+All discussions around the tradeoffs that were made must consider this - if you disagree with a decision you MUST articulate why the decision was probably made before you argue against it. Eg. "X seem to be used because of benefit [a] and their downside [b] is mitigated by [c] BUT I do not think this is enough because of [d]"
+
+We do not tolerate wasting the maintainers time and forcing them to articulate this nuance. If something is not clear of course you can ask for clarification.

package/.github/workflows/docs.yml

@@ -0,0 +1,39 @@
+name: docs
+
+on:
+  # Trigger the workflow every time you push to the `main` branch
+  # Using a different branch name? Replace `main` with your branch’s name
+  push:
+    branches: [master]
+  # Allows you to run this workflow manually from the Actions tab on GitHub.
+  workflow_dispatch:
+
+# Allow this job to clone the repo and create a page deployment
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout your repository using git
+        uses: actions/checkout@v4
+      - name: Install, build, and upload your site
+        uses: withastro/action@v3
+        with:
+          path: www
+
+  deploy:
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4
+        with:
+          path: www

package/.github/workflows/format.yml

@@ -0,0 +1,26 @@
+name: format
+
+on:
+  push:
+    branches: [master]
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  format:
+    runs-on: ubuntu-latest
+
+    permissions:
+      contents: write
+      pull-requests: write
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{ github.head_ref }}
+          fetch-depth: 0
+      - uses: oven-sh/setup-bun@v2
+      - run: |
+          git config --local user.email "github-actions[bot]@users.noreply.github.com"
+          git config --local user.name "github-actions[bot]"
+          ./scripts/format

package/.github/workflows/release.yml

@@ -0,0 +1,28 @@
+name: release
+
+on:
+  push:
+    branches:
+      - master
+
+permissions:
+  contents: write
+  pull-requests: write
+
+concurrency: ${{ github.workflow }}-${{ github.ref }}
+
+jobs:
+  release:
+    name: release
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: oven-sh/setup-bun@v2
+      - run: bun install
+      - id: changesets
+        uses: changesets/action@v1
+        with:
+          publish: bun run release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

package/.github/workflows/test.yml

@@ -0,0 +1,20 @@
+name: test
+
+on:
+  push:
+    branches: [master]
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+      - uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+      - run: bun install
+      - run: cd packages/openauth && bun run build
+      - run: cd packages/openauth && bun test

package/.prettierrc

@@ -0,0 +1,3 @@
+{
+  "semi": false,
+}

package/CNAME

@@ -0,0 +1 @@
+openauth.js.org

package/FARMS_RELEASE.md

@@ -0,0 +1,82 @@
+# Farms OpenAuth Release Runbook
+
+This fork currently tracks `farms/react-native-client` and is consumed by Farms.
+
+## Goal
+
+Publish a consumable npm package release so downstream apps do not need git-monorepo dependency tricks.
+
+## Prerequisites
+
+- npm token with publish permissions
+- git push rights to this fork
+- Bun available locally
+
+## 1) Prepare branch
+
+```bash
+git checkout farms/react-native-client
+git pull --ff-only
+```
+
+## 2) Install and verify
+
+```bash
+bun install
+cd packages/openauth
+bun test
+bun run build
+cd ../..
+```
+
+## 3) Version the package
+
+This repo already includes a pending changeset for a Farms patch release.
+
+```bash
+bunx changeset version
+```
+
+Expected updates include:
+
+- `packages/openauth/package.json` version bump (eg `0.4.3-farms.2`)
+- `packages/openauth/CHANGELOG.md` entry
+
+## 4) Publish
+
+```bash
+bun run release
+```
+
+Release workflow notes:
+
+- Root `release` runs build for `@farmsdotmarket/openauth` then `changeset publish`.
+- Ensure `NPM_TOKEN` is configured in your shell or CI.
+
+## 5) Update Farms consumer repo
+
+After publish, in Farms:
+
+1. Replace git dependency pins with published npm version in:
+   - `package.json`
+   - `packages/auth/package.json`
+   - `packages/lambda/package.json`
+   - `packages/mobile/package.json`
+   - `packages/web/package.json`
+2. Reinstall lockfile (`pnpm install`).
+3. Validate imports:
+   - `@openauthjs/openauth`
+   - `@openauthjs/openauth/client`
+   - `@openauthjs/openauth/subject`
+4. Run `pnpm -r typecheck`.
+5. Run SST build path (`sst dev` or deploy preview).
+
+## Consume in Farms (keep current imports)
+
+Use npm aliasing in consumer manifests:
+
+```json
+"@openauthjs/openauth": "npm:@farmsdotmarket/openauth@0.4.3-farms.2"
+```
+
+This preserves all existing import paths in application code.

package/LICENSE

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2024 SST
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+

package/PATCHES.md

@@ -0,0 +1,32 @@
+# Farms OpenAuth Fork Patches
+
+This fork branch contains Farms-specific patches for React Native compatibility and security hardening.
+
+## 1) React Native client export and mobile-safe client entry
+- Fork patch:
+  - Added `./client` export condition with `react-native` target in `packages/openauth/package.json`.
+  - Added `packages/openauth/src/client-native.ts` with a minimal mobile-safe surface:
+    - `authorize`
+    - `exchange`
+    - `refresh`
+  - Added `packages/openauth/test/client-native.test.ts`.
+- Upstream related work:
+  - https://github.com/anomalyco/openauth/pull/222 (Expo/React Native example)
+  - https://github.com/anomalyco/openauth/pull/136 (platform-specific dependency cleanup)
+
+## 2) Runtime import portability fix for timing-safe compare
+- Fork patch:
+  - Replaced Node-only `node:crypto` import in `packages/openauth/src/random.ts`.
+  - Implemented runtime-agnostic constant-time string compare for equal-length strings.
+- Upstream related work:
+  - https://github.com/anomalyco/openauth/pull/93 (OTP bias and timing attack work)
+  - https://github.com/anomalyco/openauth/pull/136 (platform-specific dependency cleanup)
+
+## 3) Client issuer security guardrails
+- Fork patch:
+  - Added issuer validation in `packages/openauth/src/client.ts` and `packages/openauth/src/client-native.ts`.
+  - Requires `https` issuer except for localhost/loopback development hosts.
+  - Added tests in `packages/openauth/test/client.test.ts`.
+- Upstream related work:
+  - https://github.com/anomalyco/openauth/pull/305 (redirect URI security hardening)
+  - https://github.com/anomalyco/openauth/pull/309 (JWT audience validation hardening)

package/README.md

@@ -0,0 +1,311 @@
+<p align="center">
+  <a href="https://openauth.js.org">
+    <picture>
+      <source srcset="https://raw.githubusercontent.com/toolbeam/identity/main/openauth/logo-dark.svg" media="(prefers-color-scheme: dark)">
+      <source srcset="https://raw.githubusercontent.com/toolbeam/identity/main/openauth/logo-light.svg" media="(prefers-color-scheme: light)">
+      <img src="https://raw.githubusercontent.com/toolbeam/identity/main/openauth/logo-light.svg" alt="OpenAuth logo">
+    </picture>
+  </a>
+</p>
+<p align="center">
+  <a href="https://sst.dev/discord"><img alt="Discord" src="https://img.shields.io/discord/983865673656705025?style=flat-square&label=Discord" /></a>
+  <a href="https://www.npmjs.com/package/@openauthjs/openauth"><img alt="npm" src="https://img.shields.io/npm/v/%40openauthjs%2Fcore?style=flat-square" /></a>
+  <a href="https://github.com/toolbeam/openauth/actions/workflows/release.yml"><img alt="Build status" src="https://img.shields.io/github/actions/workflow/status/toolbeam/openauth/release.yml?style=flat-square&branch=master" /></a>
+</p>
+
+---
+
+[OpenAuth](https://openauth.js.org) is a standards-based auth provider for web apps, mobile apps, single pages apps, APIs, or 3rd party clients. It is currently in beta.
+
+- **Universal**: You can deploy it as a standalone service or embed it into an existing application. It works with any framework or platform.
+- **Self-hosted**: It runs entirely on your infrastructure and can be deployed on Node.js, Bun, AWS Lambda, or Cloudflare Workers.
+- **Standards-based**: It implements the OAuth 2.0 spec and is based on web standards. So any OAuth client can use it.
+- **Customizable**: It comes with prebuilt themeable UI that you can customize or opt out of.
+
+<picture>
+  <source srcset="https://raw.githubusercontent.com/toolbeam/identity/main/openauth/assets/themes-dark.png" media="(prefers-color-scheme: dark)">
+  <source srcset="https://raw.githubusercontent.com/toolbeam/identity/main/openauth/assets/themes-light.png" media="(prefers-color-scheme: dark)">
+  <img src="https://raw.githubusercontent.com/toolbeam/identity/main/openauth/assets/themes-light.png" alt="OpenAuth themes">
+</picture>
+
+## Quick Start
+
+If you just want to get started as fast as possible you can jump straight into the [code examples](https://github.com/toolbeam/openauth/tree/master/examples) folder and copy paste away. There are also [SST components](https://sst.dev/docs/component/aws/auth) for deploying everything OpenAuth needs.
+
+## Approach
+
+While there are many open source solutions for auth, almost all of them are libraries that are meant to be embedded into a single application. Centralized auth servers typically are delivered as SaaS services - eg Auth0 or Clerk.
+
+OpenAuth instead is a centralized auth server that runs on your own infrastructure and has been designed for ease of self hosting. It can be used to authenticate all of your applications - web apps, mobile apps, internal admin tools, etc.
+
+It adheres mostly to OAuth 2.0 specifications - which means anything that can speak OAuth can use it to receive access and refresh tokens. When a client initiates an authorization flow, OpenAuth will hand off to one of the configured providers - this can be third party identity providers like Google, GitHub, etc or built in flows like email/password or pin code.
+
+Because it follows these specifications it can even be used to issue credentials for third party applications - allowing you to implement "login with myapp" flows.
+
+OpenAuth very intentionally does not attempt to solve user management. We've found that this is a very difficult problem given the wide range of databases and drivers that are used in the JS ecosystem. Additionally it's quite hard to build data abstractions that work for every use case. Instead, once a user has identified themselves OpenAuth will invoke a callback where you can implement your own user lookup/creation logic.
+
+While OpenAuth tries to be mostly stateless, it does need to store a minimal amount of data (refresh tokens, password hashes, etc). However this has been reduced to a simple KV store with various implementations for zero overhead systems like Cloudflare KV and DynamoDB. You should never need to directly access any data that is stored in there.
+
+There is also a themeable UI that you can use to get going without implementing any designs yourself. This is built on top of a lower level system so you can copy paste the default UI and tweak it or opt out entirely and implement your own.
+
+Finally, OpenAuth is created by the maintainers of [SST](https://sst.dev) which is a tool to manage all the infrastructure for your app. It contains components for OpenAuth that make deploying it to AWS or Cloudflare as simple as it can get.
+
+## Tutorial
+
+We'll show how to deploy the auth server and then a sample app that uses it.
+
+### Auth server
+
+Start by importing the `issuer` function from the `@openauthjs/openauth` package.
+
+```ts
+import { issuer } from "@openauthjs/openauth"
+```
+
+OpenAuth is built on top of [Hono](https://github.com/honojs/hono) which is a minimal web framework that can run anywhere. The `issuer` function creates a Hono app with all of the auth server implemented that you can then deploy to AWS Lambda, Cloudflare Workers, or in a container running under Node.js or Bun.
+
+The `issuer` function requires a few things:
+
+```ts
+const app = issuer({
+  providers: { ... },
+  storage,
+  subjects,
+  success: async (ctx, value) => { ... }
+})
+```
+
+First we need to define some providers that are enabled - these are either third party identity providers like Google, GitHub, etc or built in flows like email/password or pin code. You can also implement your own. Let's try the GitHub provider.
+
+```ts
+import { GithubProvider } from "@openauthjs/openauth/provider/github"
+
+const app = issuer({
+  providers: {
+    github: GithubProvider({
+      clientID: process.env.GITHUB_CLIENT_ID!,
+      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
+      scopes: ["user:email"],
+    }),
+  },
+  ...
+})
+```
+
+Providers take some configuration - since this is a third party identity provider there is no UI to worry about and all it needs is a client ID, secret and some scopes. Let's add the password provider which is a bit more complicated.
+
+```ts
+import { PasswordProvider } from "@openauthjs/openauth/provider/password"
+
+const app = issuer({
+  providers: {
+    github: ...,
+    password: PasswordProvider(...),
+  },
+  ...
+})
+```
+
+The password provider is quite complicated as username/password involve a lot of flows so there are a lot of callbacks to implement. However you can opt into the default UI which has all of this already implemented for you. The only thing you have to specify is how to send a code for forgot password/email verification. In this case we'll log the code but you would send this over email.
+
+```ts
+import { PasswordProvider } from "@openauthjs/openauth/provider/password"
+import { PasswordUI } from "@openauthjs/openauth/ui/password"
+
+const app = issuer({
+  providers: {
+    github: ...,
+    password: PasswordProvider(
+      PasswordUI({
+        sendCode: async (email, code) => {
+          console.log(email, code)
+        },
+      }),
+    ),
+  },
+  ...
+})
+```
+
+Next up is the `subjects` field. Subjects are what the access token generated at the end of the auth flow will map to. Under the hood, the access token is a JWT that contains this data. You will likely just have a single subject to start but you can define additional ones for different types of users.
+
+```ts
+import { object, string } from "valibot"
+
+const subjects = createSubjects({
+  user: object({
+    userID: string(),
+    // may want to add workspaceID here if doing a multi-tenant app
+    workspaceID: string(),
+  }),
+})
+```
+
+Note we are using [valibot](https://github.com/fabian-hiller/valibot) to define the shape of the subject so it can be validated properly. You can use any validation library that is following the [standard-schema specification](https://github.com/standard-schema/standard-schema) - the next version of Zod will support this.
+
+You typically will want to place subjects in its own file as it can be imported by all of your apps. You can pass it to the issuer in the `subjects` field.
+
+```ts
+import { subjects } from "./subjects.js"
+
+const app = issuer({
+  providers: { ... },
+  subjects,
+  ...
+})
+```
+
+Next we'll implement the `success` callback which receives the payload when a user successfully completes a provider flow.
+
+```ts
+const app = issuer({
+  providers: { ... },
+  subjects,
+  async success(ctx, value) {
+    let userID
+    if (value.provider === "password") {
+      console.log(value.email)
+      userID = ... // lookup user or create them
+    }
+    if (value.provider === "github") {
+      console.log(value.tokenset.access)
+      userID = ... // lookup user or create them
+    }
+    return ctx.subject("user", {
+      userID,
+      'a workspace id'
+    })
+  }
+})
+```
+
+Note all of this is typesafe - based on the configured providers you will receive different properties in the `value` object. Also the `subject` method will only accept properties. Note - most callbacks in OpenAuth can return a `Response` object. In this case if something goes wrong, you can return a `Response.redirect("...")` sending them to a different place or rendering an error.
+
+Next we have the `storage` field which defines where things like refresh tokens and password hashes are stored. If on AWS we recommend DynamoDB, if on Cloudflare we recommend Cloudflare KV. We also have a MemoryStore used for testing.
+
+```ts
+import { MemoryStorage } from "@openauthjs/openauth/storage/memory"
+
+const app = issuer({
+  providers: { ... },
+  subjects,
+  async success(ctx, value) { ... },
+  storage: MemoryStorage(),
+})
+```
+
+And now we are ready to deploy! Here's how you do that depending on your infrastructure.
+
+```ts
+// Bun
+export default app
+
+// Cloudflare
+export default app
+
+// Lambda
+import { handle } from "hono/aws-lambda"
+export const handler = handle(app)
+
+// Node.js
+import { serve } from "@hono/node-server"
+serve(app)
+```
+
+You now have a centralized auth server. Test it out by visiting `/.well-known/oauth-authorization-server` - you can see a live example [here](https://auth.terminal.shop/.well-known/oauth-authorization-server).
+
+### Auth client
+
+Since this is a standard OAuth server you can use any libraries for OAuth and it will work. OpenAuth does provide some light tooling for this although even a manual flow is pretty simple. You can create a client like this:
+
+```ts
+import { createClient } from "@openauthjs/openauth/client"
+
+const client = createClient({
+  clientID: "my-client",
+  issuer: "https://auth.myserver.com", // url to the OpenAuth server
+})
+```
+
+#### SSR Sites
+
+If your frontend has a server component you can use the code flow. Redirect the user here
+
+```ts
+const { url } = await client.authorize(
+  <redirect-uri>,
+  "code"
+)
+```
+
+You can make up a `client_id` that represents your app. This will initiate the auth flow and user will be redirected to the `redirect_uri` you provided with a query parameter `code` which you can exchange for an access token.
+
+```ts
+// the redirect_uri is the original redirect_uri you passed in and is used for verification
+const tokens = await client.exchange(query.get("code"), redirect_uri)
+console.log(tokens.access, tokens.refresh)
+```
+
+You likely want to store both the access token and refresh token in an HTTP only cookie so they are sent up with future requests. Then you can use the `client` to verify the tokens.
+
+```ts
+const verified = await client.verify(subjects, cookies.get("access_token")!, {
+  refresh: cookies.get("refresh_token") || undefined,
+})
+console.log(
+  verified.subject.type,
+  verified.subject.properties,
+  verified.refresh,
+  verified.access,
+)
+```
+
+Passing in the refresh token is optional but if you do, this function will automatically refresh the access token if it has expired. It will return a new access token and refresh token which you should set back into the cookies.
+
+#### SPA Sites, Mobile apps, etc
+
+In cases where you do not have a server, you can use the `token` flow with `pkce` on the frontend.
+
+```ts
+const { challenge, url } = await client.authorize(<redirect_uri>, "code", { pkce: true })
+localStorage.setItem("challenge", JSON.stringify(challenge))
+location.href = url
+```
+
+When the auth flow is complete the user's browser will be redirected to the `redirect_uri` with a `code` query parameter. You can then exchange the code for access/refresh tokens.
+
+```ts
+const challenge = JSON.parse(localStorage.getItem("challenge"))
+const exchanged = await client.exchange(
+  query.get("code"),
+  redirect_uri,
+  challenge.verifier,
+)
+if (exchanged.err) throw new Error("Invalid code")
+localStorage.setItem("access_token", exchanged.tokens.access)
+localStorage.setItem("refresh_token", exchanged.tokens.refresh)
+```
+
+Then when you make requests to your API you can include the access token in the `Authorization` header.
+
+```ts
+const accessToken = localStorage.getItem("access_token")
+fetch("https://auth.example.com/api/user", {
+  headers: {
+    Authorization: `Bearer ${accessToken}`,
+  },
+})
+```
+
+And then you can verify the access token on the server.
+
+```ts
+const verified = await client.verify(subjects, accessToken)
+console.log(verified.subject)
+```
+
+---
+
+OpenAuth is created by the maintainers of [SST](https://sst.dev).
+
+**Join our community** [Discord](https://sst.dev/discord) | [YouTube](https://www.youtube.com/c/sst-dev) | [X.com](https://x.com/SST_dev)

package/bunfig.toml

@@ -0,0 +1,2 @@
+[install]
+exact = true