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

Use-case:

  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. View a git diff-tree in a reasonable format
  3. git reset --soft and going back to the latest commit
  4. Using git-shell and restricting developers to commit to their own projects
  5. Setting up different git roots for different modules in same project - Intellij IDEA
  6. Switching remote to a specific branch
  7. git-tfs: How do I clone a tfs project that contains spaces
  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 (https://developer.github.com/v3/oauth/#scopes).

  • Getting Git GUI to Ignore Space Changes in its diff View
  • IntelliJ Idea with Git: when automatic merge crashed, how can I continue to merge manually
  • npm install private github repositories by dependency in package.json
  • How do I make git accept mode changes without accepting all text changes?
  • List all commits (across all branches) for a given file
  • git commit in pre-push hook
  • 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.