# Authentication Flow in FckSignups: Server-Side GitHub Token Architecture

> Explore the FckSignups authentication flow. Discover how server-side GitHub token architecture in Cloudflare Workers secures privileged actions for the BraveOPotato/FckSignups repository.

- Repository: [Abdullah/FckSignups](https://github.com/BraveOPotato/FckSignups)
- Tags: architecture
- Published: 2026-09-07

---

**FckSignups does not implement a traditional user login system; instead, all privileged actions are authenticated server-side by a Cloudflare Worker using a single secret GitHub token to create repository issues.**

The **FckSignups** repository eliminates client-side authentication entirely, delegating all sensitive operations to a **Cloudflare Worker** that acts as a secure intermediary to GitHub. This architecture ensures that authentication credentials never reach the browser while enabling users to submit tools, report issues, and suggest new features through a simple API.

## How the Server-Side Authentication Flow Works

### Step 1: CORS Origin Validation

When a client initiates a request to `/submit-tool`, `/report-tool`, or `/suggest-tool`, the worker first inspects the **Origin** header against a whitelist defined in [`cloudflare-worker/utils.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/cloudflare-worker/utils.ts). If the request is an `OPTIONS` preflight, the worker immediately returns a `204` response to satisfy CORS requirements before any authentication logic executes.

### Step 2: Request Routing and Handler Dispatch

In [`cloudflare-worker/worker.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/cloudflare-worker/worker.ts), the incoming request path is examined and dispatched to the appropriate handler based on the endpoint:

```typescript
switch (url.pathname) {
  case "/submit-tool":   return await handleSubmitTool(request, env, origin);
  case "/report-tool":   return await handleReportTool(request, env, origin);
  case "/suggest-tool":  return await handleSuggestTool(request, env, origin);
}

```

Each handler—`handleSubmitTool`, `handleReportTool`, and `handleSuggestTool`—resides in the `cloudflare-worker/urlHandlers/` directory and receives the request environment containing the authentication credentials.

### Step 3: GitHub Token Authentication

The worker authenticates to the GitHub REST API using a **Bearer token** stored as a Cloudflare secret. The `GITHUB_TOKEN` is injected into the worker's environment via Wrangler (set using `wrangler secret put`) and accessed through `env.GITHUB_TOKEN` as defined in the `Env` interface in [`utils.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/utils.ts).

The token must include the **`repo` scope** to create issues on the target repository. Each handler constructs the authorization header exactly as shown in [`handleSubmitTool.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/handleSubmitTool.ts):

```typescript
const headers = {
  "Content-Type": "application/json",
  "Authorization": `Bearer ${env.GITHUB_TOKEN}`,
};

```

### Step 4: Creating Issues via GitHub REST API

With authentication established, the worker sends a `POST` request to `https://api.github.com/repos/${env.GITHUB_REPO_OWNER}/${env.GITHUB_REPO_NAME}/issues`. GitHub validates the Bearer token, creates the issue, and returns a JSON response that the worker forwards to the client wrapped with CORS headers via the `jsonResponse` helper.

## Client-Server Communication Pattern

Since the authentication flow occurs entirely server-side, the client submits data without any authentication headers:

```javascript
async function submitTool(payload) {
  const response = await fetch("https://fcksignups.com/submit-tool", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload),
  });
  return await response.json();
}

```

The client never handles tokens, sessions, or credentials, reducing the attack surface and eliminating the need for complex frontend authentication logic.

## Security Architecture Benefits

This **server-to-server authentication** model provides specific security advantages:

- **Token Isolation**: The `GITHUB_TOKEN` never leaves the Cloudflare Worker environment and is not exposed to browser networks
- **No Session Management**: Eliminates complexities of JWT storage, cookie handling, or OAuth redirect flows
- **Origin Restriction**: The CORS whitelist in [`cloudflare-worker/utils.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/cloudflare-worker/utils.ts) prevents unauthorized domains from triggering GitHub operations
- **Scoped Permissions**: The single token can be limited to issue creation on a specific repository, following the principle of least privilege

## Summary

- FckSignups uses a **Cloudflare Worker** to proxy all privileged operations to GitHub, eliminating traditional user authentication
- **No user login system** exists; authentication is handled exclusively server-side via a secret GitHub token
- The `GITHUB_TOKEN` requires the **`repo` scope** and is stored as a Cloudflare Worker secret, accessible only within the worker environment
- CORS origin validation occurs in [`cloudflare-worker/utils.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/cloudflare-worker/utils.ts) before processing any requests
- Handlers in `cloudflare-worker/urlHandlers/` manage the authenticated GitHub API calls using `Bearer ${env.GITHUB_TOKEN}` headers
- Client applications send unauthenticated requests to the worker, which adds the authorization token before contacting GitHub's REST API

## Frequently Asked Questions

### Does FckSignups require users to log in?

No. FckSignups does not implement a user-level login system or session management. All authentication happens on the server side between the Cloudflare Worker and GitHub's API. Users can submit tools or reports without creating accounts, providing passwords, or handling tokens.

### How is the GitHub token secured in FckSignups?

The token is stored as a **Cloudflare Worker secret** using Wrangler's secret management command (`wrangler secret put`). It is accessed via the `env` parameter within the worker functions defined in [`worker.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/worker.ts) and is never exposed to client-side code, browser storage, or network logs.

### What GitHub permissions does the Cloudflare Worker need?

The `GITHUB_TOKEN` must have the **`repo` scope** to create issues on the repository. This scope allows the worker to submit tools, reports, and suggestions as GitHub issues while limiting other repository permissions based on the specific token configuration set in the GitHub account.

### How does FckSignups prevent unauthorized API requests?

The worker validates the **Origin** header against a whitelist defined in [`cloudflare-worker/utils.ts`](https://github.com/BraveOPotato/FckSignups/blob/main/cloudflare-worker/utils.ts), rejecting requests from unknown domains. Additionally, since the GitHub token resides only in the worker's secure environment variables, unauthorized clients cannot directly access the GitHub API even if they discover the endpoint URLs.