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. Get output of FOR with EOF in bash
  3. git reset asks 'more?'
  4. git merge somehow merged “both ways” (A to B and B to A) in one commit
  5. Is there a way to make git more verbose while pulling from a repo.?
  6. Bash. Line-by-line output into another procedure
  7. How to create multi-branch project with Jenkins DSL plugin?
  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 (

  • Should *.xccheckout files in Xcode5 be ignored under VCS?
  • git log: contributors list since certain tag?
  • Display gitk log in reverse order
  • The git ssh agent is running but is not saving my username or password
  • Create pre-push hook to lint/test
  • Heroku Create Command Yielding “ENOENT” Error
  • 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.