Our backend already uses #11 for authentication. Add GitHub codebase linking so authenticated users can connect repositories to a workspace and the backend can inspect Git history, commits, branches, and repository metadata.
Better Auth should be used for user identity and account linking only. Repository authorization should be implemented separately through a GitHub App installation flow so selected repositories can be mapped back to the authenticated Better Auth user or organization.
Goal: allow an authenticated user to connect GitHub repositories to their workspace so backend services can inspect Git history for those repositories.
Proposed approach:
- Configure GitHub as a Better Auth social provider.
- Add
GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET.
- Enable GitHub account linking for logged-in users.
- Use this for identity only, not as the primary repository authorization mechanism.
- Add backend data model for linked codebases.
Suggested models:
git_provider {
id
workspaceId
userId
provider
providerAccountId
githubInstallationId
createdAt
updatedAt
}
codebase {
id
organizationId
connectionId
provider
owner
name
fullName
providerRepositoryId
defaultBranch
cloneUrl
isPrivate
linkedByUserId
createdAt
updatedAt
}
- Add API routes.
GET /api/integrations/github/connect to start the GitHub App installation flow.
GET /api/integrations/github/callback to validate the Better Auth session, store the installation ID, fetch selected repositories, and persist linked repositories.
GET /api/integrations/repositories to return repositories linked to the current workspace.
DELETE /api/integrations/repositories/:id to unlink a repository from the workspace.
- Add a backend service for GitHub API access.
- Exchange GitHub App credentials for an installation access token.
- Fetch repository metadata.
- Handle token expiration internally.
- Never expose installation tokens to the frontend.
- Add security and authorization checks.
- Only authenticated users can start the GitHub connection flow.
- Only workspace admins or owners can link or unlink repositories.
- Repository access is scoped to the workspace where it was linked.
- Backend does not expose GitHub access tokens to the client.
- GitHub installation tokens are generated server-side only.
- If a GitHub App installation is revoked, the app marks the connection as disconnected or fails gracefully.
- Add initial git-history inspection capability.
Notes:
Better Auth handles authentication and social account linking. GitHub App installation handles repository authorization. Keep these concerns separate so users can sign in with one method while repository access remains scoped, auditable, and revocable.
This work should stay aligned with the existing topology work in #15, #19, and #20.
Our backend already uses #11 for authentication. Add GitHub codebase linking so authenticated users can connect repositories to a workspace and the backend can inspect Git history, commits, branches, and repository metadata.
Better Auth should be used for user identity and account linking only. Repository authorization should be implemented separately through a GitHub App installation flow so selected repositories can be mapped back to the authenticated Better Auth user or organization.
Goal: allow an authenticated user to connect GitHub repositories to their workspace so backend services can inspect Git history for those repositories.
Proposed approach:
GITHUB_CLIENT_IDandGITHUB_CLIENT_SECRET.Suggested models:
GET /api/integrations/github/connectto start the GitHub App installation flow.GET /api/integrations/github/callbackto validate the Better Auth session, store the installation ID, fetch selected repositories, and persist linked repositories.GET /api/integrations/repositoriesto return repositories linked to the current workspace.DELETE /api/integrations/repositories/:idto unlink a repository from the workspace.Notes:
Better Auth handles authentication and social account linking. GitHub App installation handles repository authorization. Keep these concerns separate so users can sign in with one method while repository access remains scoped, auditable, and revocable.
This work should stay aligned with the existing topology work in #15, #19, and #20.