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


  1. Command-line application (which is deployed to a 3rd party machine) needs to be able to download a tarball copy of a private repo that belongs to an organization via the GitHub API (v3)

  2. Migrate TFS 2013 to Git
  3. fatal: Not a git repository - Error
  4. How to find last merge in git?
  5. Is it possible to preserve git version history for moved files when splitting a repository?
  6. Integrating Gitlab with ReviewBoard - File Blob vs. Commit SHA1
  7. Avoiding “warning: There are too many unreachable loose objects” during git svn clone/fetch
  8. Application should only be able to access this one private repo and no other repos with read-only permission.

I have been able to accomplish (1) by creating an authorization for the application after registering a client_id/secret on my github account. However, it does not seem that the tokens returned by the authorization allow read-only access to the repo nor are they restricted to one repo (e.g. one could potentially use the token to modify this repo along with others belonging to the organization).

Is it possible to restrict access via the proper scope? I don’t see anything relevant in the API docs (

  • Git svn: how do I work with “partial” branches?
  • Gerrit & modifying Non-Interactive Users
  • git-subtree: Push changes from an cloned repo
  • Why does `git merge-base` prepares a hypothetical merge commit when more than 3 commits are supplied?
  • Which commit hash to undo a pushed merge using git-revert?
  • Unable to get complete patch with git
  • One Solution collect form web for “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.

    Git Baby is a git and github fan, let's start git clone.