[Feedback tracking] Fine-grained personal access tokens

[hpsin]

This topic serves as an area for feedback and discussion on the new fine-grained personal access tokens format, launched on October 18th. It includes more permissions, mandatory expirations, and organization + repository scoping. You can find more details in the blog post and the documentation.

There are some limits to fine-grained PATs that we'll be addressing in the coming months:

• Multi-organization support, including collaborator support, inner-source, and open-source

Recently, we've added:

• APIs to allow organization owners to programmatically manage the PATs that target their organization
• Support for GraphQL

There are also some APIs that do not yet support the fine-grained permission model, that we'll be adding support for in time:

• Packages
• Projects
• Notifications

Please let us know what you'd love to see in this new token type, what worked for you, and what didn't. Thank you!

[DanTheMan827]

Will there be a way to create tokens that don't expire for CI?

[davidcorrigan714]

I like the expiration, but I also think GH is lacking in alternative authentication methods at the moment. For enterprise users they really need Service Principal support which I think is on the roadmap. Mapping GH action tokens to roles in an account would be really nice too, don't think there's a way to do that today. We're working on setting up Hashicorp Vault and plan to use that in conjunction with a GH App which will let us translate GH action tokens, and Azure DevOps WIF tokens, into roles in GH. Just wish the time limit on the app tokens were a bit longer. Some of scripts aren't the snappiest so it'll take a bit of work to acquire the tokens at the right time.

[cu]

Secrets with a limited lifespan are a good, industry-standard security measure.

However, renewing secrets with an expiration date should not be a manual process. If there is no provision to automate access token renewal (as seems to be the case), then it's not a question of if your automated systems that rely on the GitHub API break, it's a matter of when.

For reference, see how Let's Encrypt solved HTTPS certificates on the web. They didn't just provide an API for acquiring certificates, they also created tools to automatically rotate them periodically with ZERO human intervention.

API tokens need the same.

[29039]

At least allow the same token to be renewed (even if already expired) rather than regenerating it.

[rebeccahum]

I agree with some of the posters above saying expiry isn't the issue (it isn't) - it's the lack of tools provided for automating rotation of fine-grained PATs.

[laurenty]

Ignoring the lack of tooling for automation for now, better manual tools would help with FGPAT rotation.
On existing FGPATs, there is a "regenerate token" button, but it instantly invalidates the old one which isn't useful for rotation.Something similar to what AWS does for rotation of IAM credentials (allows 2 access keys) would help.
Another option could be to add a "duplicate" feature on FGPATs, so that permissions and repository scopes don't have to manually be selected.

[ljharb]

Expiry means I can't set it and forget it, and that's the entire point of granular access tokens - namely, the risk is zero because the permissions are tightly scoped.

Forced expiry also means folks will just come up with trivial ways to reissue new ones, which will defeat the purpose anyways. It's like a forced password reuse policy - it seems like it helps security, but it actually harms it.

I hope you'll reconsider forced expiry.

[jfgilmore]

What if there was the possibility of a refresh token process?

[Dobbelina2]

Expiry means I can't set it and forget it, and that's the entire point of granular access tokens - namely, the risk is zero because the permissions are tightly scoped.

Forced expiry also means folks will just come up with trivial ways to reissue new ones, which will defeat the purpose anyways. It's like a forced password reuse policy - it seems like it helps security, but it actually harms it.

I hope you'll reconsider forced expiry.

Fine-grained token, great idea i thought until i saw the expiry date.
Went to the trashcan immediately and created a classic token instead.
Some people have a life, and don't want to spend their time biting their nails while
watching the calendar for the next token update.
A fine-grained token tailored correctly, with no expiry date is light years more secure than a
classic one.

What were they thinking?

[thedoggybrad]

I suggest to Github to consider adding a no expiry option but first popup a notice that has an agree or disgaree button like a waiver that selecting this option can be dangerous and it can be possible to only allow this option only if a single repository has been selected.

But for now I am just using the classic PAT until the time when there will be no expiry option on the Fine-Grained PAT.

[not-matt]

+1 on this. I was setting up a fine grained access token with tight permissions for exactly what was required, but instead opted for a classic token simply because I need it to last more than a year... losing all the security benefits offered by a fine access token.

[29039]

At least allow the same token to be renewed (even if already expired) rather than regenerating it.

[singhprd]

A missing feature for me is being able to authenticate against GitHub packages.

Currently (buried in the docs for packages):

GitHub Packages only supports authentication using a personal access token (classic). For more information, see "Creating a personal access token."

https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages

This is compounded by the fact that apps also can't install packages.

And also by the confusing UI whereby we can add a package scope to repositories with 'fine-grained tokens':

☝️ That text sounds like you you can authenticate against GitHub packages!

This is overall a great change and thanks for your hard work getting it into beta!

🚀

[hpsin]

This is being removed until we have support from Packages for fine-grained PATs, sorry about the confusion here!

[singhprd]

No worries, thanks for the fast response! It's still the first few days of beta! 😄 🚀

[reiniertimmer]

Does this mean that the fine-grained PATs can also be used (in the future) with packages using native clients, like mvn or npm, and not just the REST API endpoints?

[hpsin]

@reiniertimmer , those native clients should just be calling the REST APIs behind the scenes, so yep, you'll be able to use it there too!

[Th3S4mur41]

I can't seem to find the proper permission to allow pushing to protected branches...
This repo uses semantic-release on push to the main branch (protected).

Semantic release then commits the package.json, the lockfile and a CHANGELOG.md to the main branch everytime it creates a new release.
That works fine with branch protection turned on when passing a regular PT of a repository admin.
The same doesn't seem to work with fine grained token...

I tried to add multiple write permissions additionally to the content one (commit status, administration) without any impact. The job is still not allowed to push to the protected branch.

Is there a way to achieve this with the current permissions or is maybe an additional (not yet existing) permission needed to make this work?

[sheerlox]

@travi how the heck did you manage to find this post so quickly 😲 you're a real lurker I swear I feel I'm under surveillance 😂

[travi]

haha 😆 just a topic that i've been watching related to understanding how it will apply to semantic-release. i've been holding off prioritizing investigation due to the expiration situation, so it looks like you are ahead of me looking deeper. would love it if you could help us update some of our docs with your findings 😉

[Th3S4mur41]

Thanks for the feedback @sheerlox
I was able to confirm that the issue has indeed been fixed 😀
The same workflow that failed in the past is now able to release just fine.

Let's hope the experience limit is next 🙏

[sheerlox]

@travi working on it, sorry for the delay 😉

[drefcot17th]

Hi

[radeksimko]

The mandatory expiration makes sense for human-oriented use cases - e.g. testing some scripts, locally running programs which interact with GitHub API etc. I have had a number of tokens I created in the past which I only discovered as still active some months or years later.

However, for tokens which are used by machines - such as in a CI - the manual rotation seems like unnecessary overhead, as was already mentioned.

Contrary to some suggestions made here though, I would say that instead of just allowing no expiry, it would make sense to somehow allow establishment of a trust relationship, such that GitHub backend does the token rotation and humans don't even need to ever see the token, let alone copy and paste it - hence further decreasing the chance of leaks. This would make sense IMO at least for the common case when the token is used within GitHub Actions.

GitHub already essentially does that with the default GITHUB_TOKEN variable, which receives permissions based on the permissions block in the workflow file: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

I don't know what the best UX for cross-org and cross-repo tokens is, but perhaps there's some inspiration to take from impersonation mechanisms in GCP, AWS or HashiCorp Vault? Active trust relationships is probably something users would still need to be reminded of regularly, but at least it takes a lot of the overhead away and arguably makes it safer by not exposing the token to humans.

[asmeurer]

Would it make sense for the expiration to be based on time of the token being inactive? I'd be fine with a one-off token that I generated for some script to automatically disable itself after a month. But it's something that I actually do use regularly, having to regenerate it even every 3 months becomes a serious hassle.

[mrgrain]

I like this idea! All I really need is to tell GitHub to put a fine-grained PAT into the environmental variable MY_TOKEN in the repo me/my_repo. And that PAT can be updated every week, or even more often! I'd even be okay with a semi-manual request to re-approve the access every X days.

The approach with GitHub Apps works fine, except in reality users are now just adding a private key to a bunch of repos and that is even less likely to get rotated.

[dgholz]

Would it make sense for the expiration to be based on time of the token being inactive?

It wouldn't, the main reason to have expiry dates on authentication credentials like PATs is to limit the amount of time that a stolen/leaked credential can be used.

Most every other authentication credential system (AWS, regular OAuth) has built-in support for refreshing a token to get a new one & invalidate the old; for some reason, GitHub PATs do not have any refresh mechanism, and no support for managing them in the API. Quite remarkable!

[29039]

At least allow the same token to be renewed (even if already expired) rather than regenerating it.

[Jackenmen]

I'm wondering, is there/will there be a way to create a fine-grained token for a repository one has collaborator permissions on? Such repositories don't seem to appear in the repository list, and no separate entries on the resource owners list are shown for such repositories.

[maya-ross]

@ljharb We'll be publishing a roadmap issue for this in our next monthly roadmap update in November. We'll try to loop back here with that for you so it's easier for you to follow along.

While we knew that this first release wouldn't enable all the workflows that people need from fine-grained PATs, we generally prefer to ship earlier and iterate with explicit feedback from our users to help make sure we're prioritising the most impactful features next.

[dvklopfenstein]

I also would like to use fine-grained tokens on a repo where I push as a collaborator.

The repo is not associated with any organizations.

I am currently using "classic tokens" as a work-around, but wish to use fine-grained.

[fffergal]

I would also really like to use fine grained tokens on personally owned repositories I am only a collaborator on. I only need git read access, if it's easier to start with one feature instead of all. I don't have admin of the repos so can't make a deployment SSH key, so I am using a classic token, when a fine grained token would make more sense. The situation is contracting work where I am setting up build and deployment including pulling from git, but customers feel better if they don't have to give me full admin access.

[melaniesaraj]

Ahhh I just spent half of my day trying to use a fine-grained token to download a private package; I overlooked the note with the list of unsupported API endpoints in this section of the documentation. I didn't figure it out until I saw the bullet points at the end of this thread!

That was pretty clearly user error, but I'm posting this to see if this was a common mistake others encountered, in which case it could be useful for User Experience to take another look and see if this info could be made more prevalent. For example, maybe it could be presented outside of a box or in a red "warning" box. Or the bullet point could be less verbose (separate out the link to the supported endpoints); or the sub-list items could exclude the extra words "REST API to manage", making them easier to process. But I think my main source of confusion was that when I was reading too quickly and I saw "only work with personal access tokens (classic)", I thought it was going to be a list of things that only work with PATs. So it might be clearer to frame it instead as things that "are not supported for fine-grained personal access tokens".

[dgholz]

Yeah, it's especially confusing that the UI for generating a new fine-grained PAT allows you to add Package permissions, which largely won't work in the way the user expects

[melaniesaraj]

Yes, that was another thing that led me astray, thanks for pointing it out! IMO that option should be hidden for now or conspicuously clarified.

[hpsin]

So sorry you hit this issue! We're removing the Packages permission until it's better supported.

[nbibler]

Just to add: I certainly attempted to create a fine-grained, organization-owned PAT with hopes of generating a read-only permission to use with GitHub Actions and Dependabot.

This would solve a lot of security gaps with the traditional PATs (ownership with the Org rather than an org member, token-level restriction to specific repositories rather than access to all with access "controlled" via secrets access restriction, etc.). But alas, this looks to be currently unsupported.

I, too, missed the call outs in the documentation.

Looking forward to this use-case someday becoming a reality!

[kim-codefresh]

Hi!
For the classic tokens, each api response header includes X-Oauth-Scopes that can easily point what is the token permissions.
Is there any plan to add something similar for the Fine-grained PAT ?

If so, is it planned for Q1 2023 as part of Organization APIs to manage fine-grained PATs ?

[zkamvar]

Is there any movement on this? We use this in our non-critical workflows to check for properly-scoped tokens and provide a helpful user-facing message when the token is missing or mis-scoped (as implemented in our check-valid-credentials action)

[rr10]

any news?

[dnzxy]

Hi @hpsin, are there any new developments on x-oauth-scope support for fine-grained PATs?

[ledoyen]

Hello @hpsin, do you have any news, or even better some time horizon for this ?

Thanks !

[violetragan]

Hello @hpsin, do you have any news, or even better some time horizon for this ?

Thanks !

[greschd]

Loving the feature 🎉 Of the listed things on the roadmap, multi-org support and packages (GHCR) API would be very useful!

Regarding the token expiry, is there some way to get notified ahead of time?

[davidcorrigan714]

Is there an actual rotation feature now??? The old one had "regenerate" which doesn't allow any overlap and then reset the SSO authorization so to do a true rotation you have to recreate a new one from scratch.

[greschd]

We send reminder emails

Good to know, thanks! Who do these go out to? The token creator, repo / org owner, or both? Is it somehow configurable?

[tarebyte]

Who do these go out to?

These go out to the token owner not the organization.

Is it somehow configurable?

Currently not.

[greschd]

Thanks for the info!

[Gitnitdun]

Y'all are hacking me

[sramekmichal]

I have personal access token (classic) with the following scope:

• repo (Full control of private repositories)
• admin:org (Full control of orgs and teams, read and write org projects)

I use this token in our organisation to manage Repository access for our GitHub Apps.
Simultaneously we want to restrict access for the classic personal access tokens and let members use only fine-grained one.

How should I use my fine-grained token with same "scope rights"?
For testing purposes I gave all access rights to my fine-grained token and it does not work in a same way as a classic one:
⚠️ Error configuring with the . Resource not accessible by personal access token

From support I got answer that The add a repository to an app installation endpoint doesn't support fine-grained personal access tokens.

Would be perfect, if GitHub will add this endpoint in the future.
Please, thanks.

[rwblokzijl]

We are running into a similar issue.

Currently we cannot create github connections to automatically link github repos in GCP. We're following this guide: https://cloud.google.com/build/docs/automating-builds/github/connect-repo-github?generation=2nd-gen#connecting_a_github_host_programmatically

When we try this using nomal PATs it works, but we ban those in our organisation for security reasons.
When we use Fine-Grained PATs google is unable to access the installations:

╷
│ Error: Error creating Connection: operation received error: error code "9", message: the user token does not have access to installations (if using a personal access token, make sure it has enough permissions), details: []
│  details: map[]
│
│   with module.voys_webhook.google_cloudbuildv2_connection.github_connection,
│   on ../../modules/voys_webhook/main.tf line 214, in resource "google_cloudbuildv2_connection" "github_connection":
│  214: resource "google_cloudbuildv2_connection" "github_connection" {
│

We think this is because some endpoints regarding installations are not supported for Fine-Grained PATs

[m5r]

Love the approach! Any plan support pre-filled links like with classic access tokens?

This is what I'm talking about:
https://github.com/settings/tokens/new?description=my-tool&scopes=repo,read:packages

[hpsin]

Great suggestion! It's something we've heard about a bit, and we're definitely interested in a templating engine to help pick the appropriate token - "I just want to push code to my repo", etc. No roadmap item for that, but something we'd like to support in the fullness of time to make this as easy to use as possible.

[matheuss]

FWIW I found that ?target_name=org_name_here works – would be fantastic if the other parameters worked too!

[Saklad5]

Could this be extended to SSH keys as well? My work keys don't really need access to my personal repositories, and vice versa.

I'd also like the ability to use GnuPG authentication subkeys for SSH without adding them separately, but that's another issue. Scoping them on a subkey-by-subkey basis would still be an improvement.

[philonor]

I think too that is is necessary and a great idea! Organizations should be in control of which access their members have.

[sethamclean]

Is it possible to require an SSH CA, disabling private ssh keys and old style tokens while retaining the ability to use fine grained tokens that are managed by our organization?

[s-marinkovic]

+1 For this. Is it possible to require SSH Certificates and use Fine Grained access tokens?

[hpsin]

Partially. You can require SSH CAs for all git access, and that doesn't block FG PAT access to the APIs. The SSH CA requirement only applies to the git protocol.

Are you looking for, instead, the ability to use FG PATs or an SSH CA via the git protocol, but not personal keys or PATs (classic)?

[rwblokzijl]

I'm happy and applaud GitHub for exploring options for fine grained access.

However, I don't think fgPATs are a sufficient solution for an enterprise product like GitHub. The current implementation/model of fgPATs will never be granular enough for everyone's use case. This feedback page is full of requests going "could x be granted without granting y". This is especially the case for enterprise users where many different roles throughout an organization need various levels of access.

Currently GitHub has many scattered forms of "access control":

• PATs
• Fine Grained PATs
• 5 roles for Repo access (read, triage, write, maintain, admin)
• Many little flags in Enterprise settings
• Many little flags in Organization settings
• Many little flags in Repository settings
• Many little flags in Branch protection settings
• PR Bypass lists
• CODEOWNERS file
• etc

The standard in the industry is RBAC, combined with various forms of principal accounts (eg. User, Team, Service account). For GitHub this could be a really flexible and strong access control model. Google Clouds fine grained permissions system that combines into roles is a good example.

I would hope to see GitHub take all the unrelated spread out "access control features". And combine them up into a unified permission system where actual fine-grained access can be granted to various principals.

[davidcorrigan714]

Is there an API for creating these access tokens? Been playing with Hashicorp Vault and would love to use these tokens to build a Vault Secrets Engine plugin.

[ps-jay]

I'm using https://github.com/martinbaillie/vault-plugin-secrets-github - it works really well.

[ranok]

I'd love to see an API to create fine-grained tokens, it looks like the PAT token API was sunset (now 404s), but there is no way to create down-scoped tokens that last longer than 1hr!

[smheidrich]

For anyone who wants to create fine-grained tokens programmatically without the App workaround, here is a hacky solution that just simulates a user clicking through GitHub's web interface: https://smheidrich.gitlab.io/github-fine-grained-token-client/ (Python library & CLI)
Obviously I would prefer a proper API as well.

[zkamvar]

I was hoping for some way to create a token with specific permissions in a low-rent way such as URL parameters (e.g. https://github.com/settings/tokens/new?scopes=public_repo&description=test%20token for a public repository-scoped token that is called "test token"). This was a nice method of doing it because the person who needs to generate the token needs to authenticate themselves in the browser and they do not need to build a bot or trust a bot.

[adrian-gierakowski]

I'm not able to download repo tarballs using a fine grained token with read-only Contents and Metada permissions for a repo

urls like the followiing don't work:

https://github.com/<owner>/<repo>/archive/<commit-sha>.tar.gz

while this works:

https://raw.githubusercontent.com/<owner>/<repo>/<commit-sha>/path/to/file

[adobayua-rpay]

This is so awful! Have no idea where to go to generate a token!

[magmanu]

Another feedback:
I expected that the expiration of a fine-grained PAT would ship a revoke event to the audit logs. Instead, the PAT died and no log entry was generated. The revoke event only showed when the PAT was rotated. That can be a bit misleading. I understand if expiry != revoked, but what really matters is that the PAT can no longer interact with the org and that's what I'd like to track in the audit.
Thanks again :)

[hpsin]

Are you looking at the organization audit logs or the user security logs? The expiration of the token should also trigger an event about grant expiration (the permission granted by the organization to the token). We've got some bugs and work in progress to fix around making tokens show up coherently for users and logs.

[magmanu]

I was looking at the organization logs.
Do you know how I can find that in the logs about grant expiration? I looked at the reference but nothing rang the bell.
Thanks for the update :)

[jjjjjjjj987]

@magmanu although there is no expired entry you may use this document as a reference for PAT events

[GregUK]

I would like the description field for the token to be larger and/or that the request reason sent to the administrator is accessible after approval.

The flow for requesting a token limits the description of the token to 120 characters making describing the token purpose to refer back to later more difficult.

The justification for approval of the token allows for greater detail but doesn't get persisted in the admin dashboard for the organisation to review why a token was granted in the first instance. This is displayed when you approve the token, however, the justification for requesting the token is not available to view after it is approved.

Having the long-form justification information helps to be kind to your future self in understanding why a token was created or granted and where it is used and keeps the information accessible within GitHub.

[ChristopheWanteeed]

Hi,
I'm happy to use Fine-grained personal access tokens to allow restricted authorizations to a third party application.
I want to give access to commits list (properties of the commit like description and date) and branches, but without access to source code and commit contents.
I don't see this option (commits & branches are dependant on contents).
Do you think it's possible ?

Thank you in advance.

[benatkin]

Downloading a private repository with read-only permissions, with git clone over https or packages, seems like a pretty basic use case. Surprised this was announced 3 months and counting before this is properly supported. Also it should support restricting the versions that can be downloaded - for instance, downloading only the latest version of the default branch.

[philpax]

Hi there,

The GET /repos/{owner}/{repo}/labels endpoint appears to be broken with fine-grained PATs. I have a fine-grained PAT with sufficient permissions, as described here - and additional permissions that I added for testing - but I am getting an internal server error:

$ curl -H "Accept: application/vnd.github+json" -H 'Authorization: Bearer a_finegrained_pat' -H "X-GitHub-Api-Version: 2022-11-28" -i https://api.github.com/repos/goatcorp/DalamudPluginsD17/labels/new%20plugin
HTTP/2 500
[headers elided...]

A classic PAT works fine:

$ curl -H "Accept: application/vnd.github+json" -H 'Authorization: Bearer a_classic_pat' -H "X-GitHub-Api-Version: 2022-11-28" -i https://api.github.com/repos/goatcorp/DalamudPluginsD17/labels/new%20plugin
HTTP/2 200
[headers elided...]

{
  /* elided */
}

The issue appears to be with this endpoint specifically, as other endpoints work:

$ curl -H "Accept: application/vnd.github+json" -H 'Authorization: Bearer a_finegrained_pat' -H "X-GitHub-Api-Version: 2022-11-28" -i https://api.github.com/repos/goatcorp/DalamudPluginsD17/pulls
HTTP/2 200 
[headers elided...]

{
  /* elided */
}

I'm fine using a classic PAT for now, but it'd be nice to see this fixed :)

[nkreiger]

Hi!

Is there a plan to support:

[GET /repositories/{repository_id}](Fetch Repository By ID)

I know this is an "undocumented" endpoint. However, it seems with the PAT it denies the abillity to query a repository it should have access to by ID. The only workaround I see is to list all repos that the token has access too, loop through, and search for a specific ID.

[vrsndanchan]

When will this feature available for self-hosted enterprise github server?

[hpsin]

We're adding it to GHES right now, and it's in final bug-bash stages. Our goal is 3.10 assuming no major problems with it.

[kuba-vodafone]

I am not sure if I am asking in correct place but could you please tell me how to check if my access token generated via Github App ("ghu_") has specific permissions?

I would like to authenticate to Vault via github token comes from Github App and I am wondering if it's possible in easy way

[hpsin]

For a GitHub user-to-server token (`ghu_*) there are these two APIs:

• https://docs.github.com/en/rest/apps/installations?apiVersion=2022-11-28#list-app-installations-accessible-to-the-user-access-token
• https://docs.github.com/en/rest/apps/oauth-applications?apiVersion=2022-11-28#check-a-token

The latter is what you want for permissions. The former handles the intersection of your app's installations and the user's access.

[danielachin]

We recently setup a FG PAT to use for GH audit log ingestion to Splunk (via the Splunk add-on for GH). A couple pieces of feedback:

1. The first time I configured a PAT, I set the owner to a dedicated service account that I had made an org owner. Turns out, I needed to set the Resource Owner of the PAT to the organization we were going to ingest logs from. When I figured out this was incorrect, I was not able to edit the PAT, I had to create a new one. Might be a nice feature to allow this to be changed.
2. As far as I can tell, the only permission the PAT needed to reach the audit logs is GET /orgs/{org}/audit-log which is under the Administration subsection of the Organization Permissions. However, you can only grant access as the Administration level itself, which gives more access than required to read the audit logs. I'd think that reading the audit logs would be a common use case, so it might be a good feature to allow for more granular control there vs requiring tokens to have read-only access to all of the Administration end points.
3. Another way to send your audit logs to external sources (like Splunk) is to use log streaming, which can be configured Enterprise level. Splunk supports this via HEC token, but we ended up using a PAT so that we could get a more feature rich solution using the Splunk add-on for GH. Based on my initial foray into FG PATs, it seems that they are limited to the Org level. Since we have multiple orgs, we needed multiple tokens. I think it would be handy to enable them at the Enterprise level, which would be very handy for reading logs from all Orgs.

[hpsin]

Thanks for the great feedback!

allow [the resource owner] to be changed.

We're looking at "Multi-targeting" which would allow you to add additional resource owner targets to the token, which would come post-GA. Allowing the token owner to revoke the resource grant and request a new one should work too, but there might be a lifecycle issue here blocking it - I'll check it out.

I'd think that reading the audit logs would be a common use case, so it might be a good feature to allow for more granular control there vs requiring tokens to have read-only access to all of the Administration end points.

Completely agreed, and that RBAC feature for custom organization roles is currently in a private beta - we're looking to take that to a public beta by September.

Enterprise PATs

💯 agreed - it's in our post-GA roadmap as well, since we can't consider PATs (Classic) fully legacy until there's full parity, including the ability to scope access to an enterprise. I don't have a timeline on this, but it's a must-do for us. The big challenge is adding the enterprise level to the fine-grained permissions model, which doesn't yet exist for users or tokens. So we'll be working on enterprise-level custom roles and token permissions at the same time (i.e. granting a user enterprise-level audit log reader permissions, and a token to match).

[bronf]

Hi all,

Please let us know what you'd love to see in this new token type, what worked for you, and what didn't.

I have a script to check the conformance of all the repositories of my organization to some security policies. In particular, I need to check that all GitHub teams having access to the repositories are all linked to an AD group. This works nicely with a basic PAT but not with a fine-grained PAT and I would like to switch to fine-grained PAT and forbid the use of basic PAT so that I can control how we access our repositories via PAT. Fine-grained PAT look very interesting but I do not want to loose the opportunity to run conformance checks with a script.

The end point I'm targetting is orgs/[org name]/teams/[team name]/team-sync/group-mappings.

Thanks

[hpsin]

Can you make sure that your token has:

1. A Resource Owner matching the org you're trying to call?
2. The Members:write permission?

That worked for me. I've filed a bug with the owning team asking them to change this to require just read permissions.

[bronf]

That's right, it works (I was missing Members:write). Thank you so much! Why do we need write permissions to just query the teams and sync groups (I had Members:read before?

[adrian-gierakowski]

Given a user with admin access on a repo, I'd like to create a token which restricted so that on a specific private repo within an org, only the following is possible:

1. fork the repo
2. create a PR from the fork to the upstream

However step 1 seems to be only possible if token has Content:write and Administration:write permissions. These permissions are far to broad for the task at hand. Ideally the token would have the following perms:

Contents Access: Read-only
Metadata Access: Read-only

Together with some new permission which would allow to create a fork and then a PR from that fork (without being able to modify any existing PRs made directly on repo on other forks). Commenting on the PR created with the token would also be nice.

Note that using classic token of a user with pull only permissions on the repo I am able to both for and create a PR, but I would like to create a token with permissions only on selected repos (out of many accessible to the user). I'd also like the user to have admin access on the repo so that a token with broader permissions could be created for other tasks.

[fadingbeat]

Hi, perhaps this question is not suppose to be asked here, but I am confused.

I wanted to use GitHub API in order to show my repositories on my personal portfolio. I have created the fine-grained PAT and everything works perfectly, but the problem is that the key is exposed in browser tools. (I've failed at setting my own proxy server, using Netlify or other solutions I've found).

Is it possible to add a restriction to the token, for example, that the token can only be accessed from a specific URL?

[hpsin]

Ah, no, I'm afraid not, the way browsers work that's not a trusted security boundary. If your app has a backend, you could store the token there, and I've definitely heard of folks doing the netlify pattern as well.