I wish GitHub would create a proper auth design. I won’t grant blanket permissions to tokens because there’s too much risk of something going wrong.

It seems dumb that they don’t have per repo tokens. I think the issue is with their licensing as if they made proper tokens users could abuse it by giving tokens to their friends. But this should be detectable in a friendly (please don’t do that) way.

I want to be able to give read-only access to private repos.

I want to be able to give fine grained function level and repo level access.

If I’m an admin on multiple repos, I want to be able to issue a token for just a single repo so I can give that to a CI job without worrying if every single repo I admin is at risk.

They allow ssh keys with some similar functionality, but ssh keys can’t be used as much as tokens.

I’ve been waiting for a story about how some third party app granted access to my whole org gets taken over and wreaks havoc. Eventually this will probably be the attack that alters real packages instead of these name overloading packages.

> It seems dumb that they don’t have per repo tokens.

Technically you can create one new GitHub account per repo and generate a token for that... But that is highly annoying :)

They need to support IAM / RBAC style policies and tie every authn+z method to those policies, but my guess is they have different auth methods strung all throughout their codebase so implementing it will take a few years. Then of course they have to make it "user friendly" as we all know how painful IAM can be...

Comically, that’s why my GitHub recommended. Of course that’s a nightmare for a user to manage, violates our sso requirement, and GitHub charges per user.

We do this at work. And you pay per user per team so we’re paying double or triple in some cases by managing access via teams.

At the moment, there's a story about github1s.com on the front page of HN and people are asking how to give it access to their company private repos [1][2]. Scary.

[1] https://news.ycombinator.com/item?id=26087017

[2] https://news.ycombinator.com/item?id=26086789

Apparently the Oauth scopes are much worse than GitHubs apps. Only GitHub apps allow read only access to the “metadata” by default whereas Oauth apps get access to the code, deploy keys, etc with no way to limit that access per repo.

https://docs.github.com/en/developers/apps/scopes-for-oauth-...

https://docs.github.com/en/rest/reference/permissions-requir...

Different access tokens have different permissions, you can't just do whatever you want.

Yeah, but at least with PATs (not sure about other token types), you can't scope them to a particular repo, so whenever you need to allow something to even see a private repo or write to a public repo, the token you supply to allow that can do that for all repos and that alone is potentially really destructive. I am not sure if there is a good reason for why PATs can't be scoped to a repository, because if they were allowed to be, it would do a lot for security I think.

Worse: you can’t even scope it to an org, and some integration points are only available to org owners!

GitHub is terrible.

That explains why at a place I worked we had multiple github orgs for different subteams, and/or they were really cheap ... yeah confused now.

We also have multiple orgs, but we hit the requirement that you only have one bot account. It would be super nice if GitHub allowed much tighter scoping for PATs.

I don’t know how many GitHub orgs the Linux Foundation has, but... hundreds? Having one bit account with wide permissions is a non starter

Most integrations just ask for blanket all permissions. They do this because it means they can give you a list of repos and let you choose which ones to integrate their service into with no work on your part except "click yes to give us permission to do everything for you and ... we'll do everything for you"