GitHub OAuth2 Token: How to restrict access to read a single private repo

I don't believe you can restrict github OAuth tokens in that way. The github docs for OAuth say that

While Git over HTTP with OAuth reduces friction for some types of applications, keep in mind that unlike deploy keys, OAuth tokens work for any repository for which the user has access.

So while you can limit the scope of the token in terms of the types of activities, you can't limit it to a subset of repos.

Deploy keys can be restricted to a single repo, but allow write access.

The obvious tactic (as mentioned by Thomas) is to create a dummy account that represents the application. Given the goals of OAuth, this might be a better workflow in any case -- it'll let you easily change the permissions the app has as if it were in fact a user.

Github even mentions/endorses this strategy explicitly, calling them machine users.

---

Deploy keys are the way to go.

By default they don't allow write access and they are scoped to the specific repository (unlike the GitHub personal access token). So you can now generate a private/public key pair, set one as read/pull only deploy key on a single repository in GitHub and use the private key in your CI.

For instance run a bash script:

eval "$(ssh-agent -s)";
ssh-add <your private deploy key>;

Now your CI has rights to access private repo's during the build.

You can add a Deploy key by going to your repository on Github and then clicking Settings > Deploy keys > Add deploy key

---

I wanted to have better access control in my Github Actions, but also have access to multiple repositories at the same time. And sure enough Deploy Keys are way to go. You can choose read/write permissions, but unfortunately you need a new pair for every new repository. Bellow I'll show you how I made it to work.

Let's assume you need to access 2 repositories from the third running Github Actions

Generate your keys ssh-keygen -N '' -t ed25519 -C "First Key Name" -f ./first_key ssh-keygen -N '' -t ed25519 -C "Second Key Name" -f ./second_key You don't need a passphrase as long as you'll remove keys from the filesystem after adding them to the secrets in the Github repository.

Add contents of *.pub files as Deploy keys of respective repositories (select write permissions if needed)

Add contents of first_key and second_key files to third repository's secrets as DEPLOY_KEY_FIRST and DEPLOY_KEY_SECOND respectively

Now you can remove generated key files - you don't want to keep them around anymore. You can always generate a new ones.

Setup workflows file name: Some automatic action on: # on push event push: # allow manual run workflow_dispatch: env: # sockets for multiple ssh agents (1 per key) SSH_AUTH_SOCK_FIRST: /tmp/ssh_agent_first.sock SSH_AUTH_SOCK_SECOND: /tmp/ssh_agent_second.sock jobs: build: runs-on: ubuntu-latest steps: # first step is to setup ssh agents - name: Setup SSH Agents run: | # load deploy keys from the secrets echo "${{ secrets.DEPLOY_KEY_FIRST }}" > ./ssh_key_first echo "${{ secrets.DEPLOY_KEY_SECOND }}" > ./ssh_key_second # set chmods (required to use keys) chmod 0600 ./ssh_key_* # start agents ssh-agent -a $SSH_AUTH_SOCK_FIRST > /dev/null ssh-agent -a $SSH_AUTH_SOCK_SECOND > /dev/null # add each key to their own ssh agent SSH_AUTH_SOCK=$SSH_AUTH_SOCK_FIRST ssh-add ./ssh_key_first SSH_AUTH_SOCK=$SSH_AUTH_SOCK_SECOND ssh-add ./ssh_key_second # you can now remove keys from the filesystem rm -f ./ssh_key_* # now you can use these keys in normal git commands - name: Clone first env: # assign relevant agent for this step SSH_AUTH_SOCK: ${{ env.SSH_AUTH_SOCK_FIRST }} run: | git clone git@github.com:user/first.git ./first - name: Clone second env: SSH_AUTH_SOCK: ${{ env.SSH_AUTH_SOCK_SECOND }} run: | git clone git@github.com:user/second.git ./second

Profit

Disclaimer

As you may guess above solution is not scaling up, and at some point you may consider setting up a Machine user (suggested in starwed's answer), which works best with organization account (even free) and gives access to Personal Access Tokens and OAuth.

---

As the top answer has suggested this is currently not possible with GitHub.

It is not a direct answer to your question, but the reason I was looking to do the same thing was to abide by policy of only allowing TCP 443 outbound from a restricted zone.

GitHub accepts SSH on TCP 443 as documented here.

TLDR: If you modify your ssh from ssh://git@github.com to ssh://git@ssh.github.com:443 it should be successful.

To set github to use TCP443 in your SSH configuration file, edit the file at ~/.ssh/config, and add this section:

Host github.com
Hostname ssh.github.com
Port 443
User git

You can test that this works with:

$ ssh -T git@github.com
> Hi username! You've successfully authenticated, but GitHub does not
> provide shell access.

---