Read-Only OAuth Scope on GitHub, Please?

[winston]

We love @github. Our processes all revolve around GitHub.

Naturally by extension, we love the GitHub API, because it allows us to do creative things with GitHub.

So far, we have built a few apps that rely heavily on GitHub's API:

• deppbot
  • A service that does automated dependency updates for Ruby apps, issued as Pull Requests
• Dasherize
  • A simple dashboard for CI and GitHub stats
• GitHub Gem Stats
  • A toy app for "Which RubyGems does X use?" and "Which GitHub repo uses Y gem?"

Let's talk about permissions next.

For both deppbot and Dasherize, we require access to both public and private repos.

Looking at GitHub's OAuth scopes, we'll need to use the repo scope.

Hmm.. But wait a minute.. The repo scope grants read AND write access to basically everything! Getting read access is probably a must for all apps, but do we need write on everything?

Due to the nature of deppbot, we'll need write permission on public and private repos, so that it can issue Pull Requests when it finishes the dependency update for a project and perform other actions.

However, all Dasherize does is read from public or private repos, and it's not doing any write at all. You can even take a look at the source code to verify that.

So isn't it intrusive to require write permission too? Definitely.

As a user, I would like all apps to only require the lowest level of permission that it needs to operate.

As a developer, I am taking on unnecessary liability when my app has permissions that it doesn't need.

Of course, we are not the first to create apps that use GitHub API, and this has been a common issue for both users and app developers for a while, for example:

• http://docs.codeclimate.com/article/258-do-i-have-to-grant-code-climate-read-write-access-to-all-of-my-github-repositories
• https://groups.google.com/forum/#!topic/travis-ci/ihZZXAw9K6M
• Hound keep asking write permission to all data of public repositories (security/dangerous) houndci/hound#925 (comment)
• https://gitter.zendesk.com/hc/en-us/articles/200176672-Authenticating-with-GitHub

By design, GitHub API does not provide any Read-only OAuth scope for public and/or private repos. Once you ask for permissions to either public and/or private repos, you'll get both read and write. What can we do then if we just want Read-only access on GitHub API?

There are definitely work arounds, as mentioned in some of the links above:

Progressive Permissioning

This means that the app shall only ask for permissions when it requires it.

Let's use @houndci as an example.

When you first sign up, @houndci only asks for access to your email and public repos read/write.

Then, it provides you with the option to "Include Private Repos".

Clicking on that, you can now grant @houndci access to both public and private repos read/write.

In this way, you only grant @houndci necessary permissions when it requires it.

But this still doesn't solve the problem if my app just requires a read scope, like Dasherize..

Manual Setup

Alternatively, maybe a manual setup of collaborators might help?

Unfortunately not.

When you add a collaborator to a GitHub repo, the collaborator naturally has read and write permissions, and you can't change it.

What about Teams (for Organization repos only)? Can it grant Read-only permissions?

Yes. That might help!

You can create a special Team in the organization, grant the Team a read-only access to the repo,
and now you have a Read-only scope. But in most cases, manual setup is not the best UX experience. 😢

Recently, GitHub also added Read-only Deploy Keys, as another option to grant Read-only access to one single repo.

Many are speculating that this eventually lead to a Read-only OAuth scope. I sure hope so.

---

In summary, we really hope that @github can provide developers with a Read-only OAuth scope, so that app developers don't have to explain ourselves every time we use the repo scope.

In both deppbot and Dasherize, we are conscious of our decision in asking for read write access to public and private repos because we went with the simplest solution for now to validate the ideas. Definitely, we should look into both Progressive Permissing or Manual Setup when the apps get enough traction and feedback from users.

Thank you for reading.

@winston ✏️ Jolly Good Code

About Jolly Good Code

We specialise in Agile practices and Ruby, and we love contributing to open source.
Speak to us about your next big idea, or check out our projects.

[bluta]

i would also love to have this - and am now creating a deploy user having only read access to all of our repos needed by our application.
👍

[ayurkows]

This is the first non-doc link from google I found when searching for how to get a read only scope.

I agree this is needed, users are going to question why we are asking for write access as well especially since it's highlighted and there's no way for them to know that we are only asking for it because we have no other option.

[alexmalik]

I would definitely use this if it was a feature, my app doesn't need the write access that the current repo scope supplies, and as a developer I know I would only want to give the minimum permissions to an app if I were the user of my app.

[jnieuwhof]

Plus one on this, breaks principle of least privilege

[sgen]

It looks like this is on the horizon

[ronaldpetty]

Can anyone with experience clarify here? I am looking for read only private repo scope, and don't see something like that in roadmap or existing settings. Maybe I am misinterpreting what was stated above.

[deftio]

I have the same question. When an outside org such as Travis or BlackDuck or whatever wants access to my public repos I just want to give them read access so they can do their thing. I don't see why I would want to give them write access so how do I set that up?

[BernieSumption]

+1! I routinely start to set up integrations, then stop half way because I remember that there's no way to allow an integration read-only access to my GitHub account. Most recent was the Trello and Slack integrations.

The ability to modify code in a repo is basically the highest privilege you could grant, second perhaps only to deleting the repo. Most integrations are convenient tools for bringing GitHub data into other systems. If they need to write data it's probably only comments and PRs. These tools provide a lot of value, but given the security risk of having keys floating around that allow write access to all my repos I sadly have to ignore them all.

[udev]

Guess we're checking in on this from August 2018... Seems to be a pretty in-demand feature request.
dear-github/dear-github#113

[Bob-Thomson-zz]

+1 as has been said, least privilege - there will always be situations where granting read only access makes sense.

[jimsmith]

+1 least privilege access there are situations in corp/enterprise world when this is a must.

[peterbosalliandercom]

And again, please add this functionality, we need this for CI/CD purposes, for example argocd which deploys apps in combination with Helm charts wich depend on a values.yaml which is stored in a private repo where the config is stored. Github is not only for developers but also voor gitops configuration. We need read only scope on personal access tokens per repo.

[NateZimmer]

psst microsoft devops can do this. cmon git. Yes i'm sure you think this would be redundant with deployment keys
Why its a superior offering to have tokens:

• It is far simpler to automate usage of these than a deployment key. SSH key setup is not a simple cross platform task to automate. Deployment keys needlessly add uneeded complexity and headache to cross platform deployment.
  I beg you git, please consider repo specific read-only tokens

[willemdh]

Read-only access oauth scope for private repositories is a much needed security feature that should also be available for pro github users..

[omairvaiyani]

I thought scrolling this far down would reveal "here you go"! I thought wrong.

[tacticz]

It is clear a LOT of (pro) GitHub users would definitely need read-only access OAuth scope on their private repos.
I'm really surprised that, more than 3 years after the initial post, GitHub still hasn't react on that matter !

[deftio]

Read Access to repos is a necessary feature.

This is true regardless of account level. The reason why is lets say a widely used 3rd party gets hacked (such as a CI provider or doc service). Then EVERY repo they have access to (means write access) could get corrupted. The scale of this kind of mayhem, even if its possibly undo-able by the individual repo owners, is poor security planning.

[anupamaj83]

Read-only access oauth scope for private repositories is a much needed security feature.

[d-rams]

Seriously! Why is this not implemented?

[datamgmt]

+1 for multiple reasons and to meet many requirements

[choonkeat]

Can consolidate eyeballs at dear-github/dear-github#113

[rmccullagh]

Yes. Please implement read only access to repository names. For example, my application only needs to show the names of the private and public repositories. I don't need anything else. Please add this :)

[rgoulter]

@jhullEO I'd suggest Deploy Keys might solve this use case for you. https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys

[jhullEO]

@rgoulter, that's not a bad idea, I'm not sure how well you can script the deployment this way (a https pull with an OAUTH token can be scripted for sure) but I'm looking into it, maybe with the github cli you can register the ssh key although I didn't see it in the tour. It's the first I've heard of Deploy Keys though, so thanks for the heads up!

[rgoulter]

@jhullEO in a CI environment where you can assume a clean environment each time, you'd have the private key as a secret. You'd use this value to write to ~/.ssh/id_rsa (and the public key of the deploy key to .pub) so that git can use it when cloning from a remote like [email protected]:<owner>/<repo>.

[RickyMarou]

It's really weird that the access is "all or nothing" when it comes to the repo permission 🤔

Letting an app modify a repository is a big deal, for a lot of folks it entails allowing the app to deploy on production 😱
Letting an app read a repository is a much easier sell, also as an app maker i absolutely do not wish to have more permissions than what I need to make my app work.

[simoneb]

I've been following this issue for years and while I agree that it would be nice to have readonly scope in OAuth, it must be said that if you're looking for fine grained permissions you should definitely consider a GitHub App, which is quite simple to set up and gives you all the permissions you need. With a GitHub App you can still authenticate the user via OAuth, which uses the same endpoints as the legacy OAuth Apps, and you have more control over permissions.

[deftio]

What I don't understand is how this isn't a giant security hole waiting to happen.
For example I've auth'd travis-ci on several of my repos. But Travis asks for r/w access to all my repos. Now gosh forbid they get hacked imagine all the repos that could be mucked around with. Not just Travis but any other tool that provides useful CI/CD/etc. It basically seems to delegate security from github to whoever the trusted provider is.
Sure its git and I could unwind etc. But the sheer amount of time plus any connected CI plus any one who pulls based on my pushes plus...
Or I just don't understand security. So if I'm missing the boat on that I'd truly appreciate it if someone explained it here.

[john012343210]

+1, I just discovered we lack the most simple and important things, that is read-only access token. I read from https://pmihaylov.com/github-readonly-api-token/

[mmseng]

Please god... Someone... help...

[ehughe5]

The work around mentioned by @AronWaterAron only works for repos owned by orgs. I was trying to do it for user account repos but didn't get that menu and then find GitHub Docs says only owner/collab permission levels are offered.
It's been 5 years, why isn't this a thing already.

[yaananth]

👋 would like to link/cross reference the reply showing the general sentiment around this (to use GitHub apps)

dear-github/dear-github#113 (comment)

[Ascendzor]

Bump 😅

[ringerc]

I'm absolute amazed there are no read-only rights on API tokens given that API tokens have a permissions system.

Yet "bot" accounts are against GitHub's ToS, so you aren't technically allowed to create a specific user for read-only access. And even if you do you run into pain as soon as you want to remove one of your org's users from that read-only access.

What exactly are we supposed to do? Manage individual SSH deploy keys on each and every repo we want read-only access for, for each user who should have such access? Use a general purpose "read only key" and widely share it - then worry about invalidating it the first time someone leaves?

Kind of astounded here.

Even worse, a personal access token does not appear to be org-scoped. So a token I'm forced to use for some should-be-read-only purpose in one org can potentially leak and compromise read/write access to other unrelated orgs and personal repos (so long as they don't use SAML).

How is this not considered a critical security issue by GH, especially with the focus on supply chain attacks happening at the moment?

[holsonjr]

Argh - plus one more.

[m4heshd]

I visit this thread usually a few times a year. Disappointment grows each time.

[jhullEO]

Well now I'd feel bad if they fixed it. It's a good chuckle every month or so.

[m4heshd]

@jhullEO github/roadmap#184

[Breiby]

How is this not a thing yet? :|

[AashJ]

😢 this still isn't included is it...

[Gby56]

Bumping this, the roadmap has no date planned. Just like previous comments said, this is seriously bad for Github runners, making things dangerous for supply chain by just pushing code to a repo from a runner.

[CerebralDatabank]

I was researching this because I was wondering why an app that I was using required full read and write access to my public repos, even though the app only needed to read them. Little did I know this would be a problem with GitHub since at least 2015 that they haven't fixed in 2021...

[choonkeat]

Comments should henceforth go directly to community/community#7891 where Github is tuning in. Thanks everyone

[jg3]

I don't understand why r/o SSH keys are a thing and r/o access token can't be. It makes me question everything.

[johnspurlock-skymethod]

Adding to the pileon - I can't believe a read-only scope does not exist!

[matanox]

One additional use case for this IMHO ― cloning a private github repo for using it in Google Colab. I can't think of another solution to cloning private repositories in Colab, Colab being an untrusted environment which is also ephemeral by nature. A personal access token with read only (clone) privileges may seem like the closest option for this light-risk scenario. Maybe I'm wrong.

[kderck]

I would also like to be able to see a Read Only scope for Private, and Public repositories in GitHub.

[deftio]

Don't worry the problem will be addressed.

Here's how:

1. There will be some cyberhack where some 3rd party with write access to 100k or 1M repos is hijacked.
2. The hack will write lots of junk into those repos.
3. A few millions services will suddenly get screwed up.
4. There will be press about how this could happen / OMG / what happens now??
5. Then Github / Microsoft team will notice and suddenly appropriately scoped permissions will be a feature.

[GitHunter0]

I'm absolute amazed there are no read-only rights on API tokens given that API tokens have a permissions system.

Yes, this is absolutely ridiculous, it's obviously not a difficult feature for @github to implement. Some things in this world are just incomprehensible.

Is there a formal response from @github about this issue?

[winston]

Please chime in on https://github.com/orgs/github-community/discussions/7891 instead. Thank you!