@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.

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.

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.

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

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?

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

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)?

github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=

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.

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.

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

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.

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.

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

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!

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.

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.

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

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?

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.

+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.

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

Thanks @AdnaneKhan - certainly a valid use case! We'd love to help organizations move off of classic PATs, and you've exactly described how we'd do this. We'd look at org-level and repo-level permissions for users that would give them the ability to bypass the restriction on PATs (classic) in that specific context. I don't have a date for you on this, but it's definitely something we'd like to build.

It would also be nice if there were some way to "approve" existing keys, but not allow new ones to be created, with a view of what tokens are currently allowed so you can iteratively help people migrate over. That's a big additional ask I'm sure, but if you're going to implement the above maybe that's something that could be incorporated.

@mbainter I believe if an Enterprise Org has SAML SSO enabled and enforced, you can use https://api.github.com/orgs/ORG/credential-authorizations to get a view of all classic PATs that have access to an org and their scopes. Could potentially combine that with auto-revoke logic (for the SAML SSO grant) if a user isn't allow-listed. Kind of a hack, but it would work!

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.

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?

Who do these go out to?

These go out to the token owner not the organization.

Is it somehow configurable?

Currently not.

Thanks for the info!

Y'all are hacking me

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

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.

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

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!

ah, that section is only regarding the approval and auditing

the "Get Started" tells that the feature is disabled for all organizations by default

Right, in the public beta we are not enabling organization access with fine-grained PATs by default, as it requires a new set of auditing processes that companies wouldn't have in place. Thus, organizations need to opt-in to this new token type. We'll update this when fine-grained PATs go to general availability, such that organizations and enterprises that haven't explicitly enabled or disabled this will have it enabled for them.

menurut https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/

Dalam tab Token Akses Peribadi baharu dalam Tetapan Organisasi, Pemilik Organisasi boleh memilih untuk meluluskan setiap PAT halus yang disasarkan oleh pembangun pada Organisasi itu atau mana-mana repositorinya. Pilihan ini didayakan secara lalai.

Walau bagaimanapun pada halaman organisasi,

ini nampaknya tidak sepadan? adakah saya salah membaca ini?

We don't support per-token IP restrictions, but we do support enterprise-wide and organization-wide IP allowlists for all access, which does cover the use of PATs. If you want granularity at the per-user level for IP allowlists, you may be able to check out the IdP-driven IP allowlist feature that's in beta for Azure AD backed Enterprise Managed Users, which will use your per-user CA policies in AAD to enforce IP range restrictions on PATs and user sign-ins.

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.

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.

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!

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

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

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

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?

@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!

Hi @hpsin
Any suggestion of good article, blog post or anything else to read how GitHub App can replace PAT ?
Thank you in advance.

Now that github has un-banned the use of bot accounts, we really need ways to effectively manage such accounts.

Any non-trivial github workflows stack will be utterly reliant on bot accounts because of baked-in github limitations on actions. Most crucially any action performed using a repo's GITHUB_TOKEN suppresses triggering of other workflows. So in practice you have to use bot accounts with PATs in workflows for a lot of things.

(Yes, well designed actions flows can use repo dispatch and workflow dispatch to work around this partially. But that tends to result in two paths-to-entry for workflows, which is hard to debug. And since github actions are nigh-untestable at the best of times and have no automated testing support whatsoever, keeping them simple is key to keeping them working.)

Now that github has un-banned the use of bot accounts, we really need ways to effectively manage such accounts.

Their terms of service only allow a single machine account per person/legal entity which I wouldn't say is generally enough.

any action performed using a repo's GITHUB_TOKEN suppresses triggering of other workflows. So in practice you have to use bot accounts with PATs in workflows for a lot of things.

We generally use GitHub App credentials to get an installation token, or write our workflows with dispatch_workflow triggers (and explicitly starting the workflow) to get around this.

Automating the refresh of tokens is a GitHub App domain, not a PAT scenario

I disagree. Because we use GitHub to host our packages, our devs need to update package tooling configuration to use their PAT. Updating these files is quite trivial, so we have our own devtools to ask for the PAT and write it to the required places. But we still need the users to click through their dev settings, and tick the right scopes, and set an expiration date, and copy-paste it correctly. It's not a huge task for them, but we need to maintain the docs explaining how to do this, and if we could call the API to do it for them (generate a new PAT from an existing (which is already present in the dev settings page), or create a new PAT with the appropriate scopes & revoke the old one), then we could drop the manual process & embed it in our devtools, write tests for it, etc.

I don't see that option, either. If it helps, I'm not a member of any public repos.

Accounts that don't have any personally owned repos won't see the option to select specific repos, since that list would be empty. That should show up for you @melaniesaraj - your account has at least 3 repos (your public ones + whatever you may have private). We'll do some more digging, but that at least explains the UI you're seeing, @MO-Lewis

@hpsin I encountered this on a different account (my work one), so that answers my Q, thanks! I expected it to show up for private repos that I had access to within my organization.

Accounts that don't have any personally owned repos won't see the option to select specific repos
Are there any plans to update this behavior? I have a service account under a Github Org and was hoping to create a PAT for it with limited repository access. The service account owns no repos, but has access to many private repos. The only options available when trying to create a PAT are "Public Repositories (read-only)" or "All repositories"

Shouldn't we be able to see org/team owned repos as well? (Where membership allows)... Specifically I'm trying to do exactly the same thing as @laurenty but am unable to list or access any private repos using the API, even though the user can see them through the UI.

Linking tokens to team scope is a definite possibility! We're looking at ways to improve the repo selection experience, for orgs that have thousands of visible repos, and this is definitely one of the popular ideas. However, it remains to be seen if we can inject that pointer, i.e. replace that list of repos with a pointer to the list of repos assigned to a team.

This would be great (I've looked but can't seem to find a way to grant access to org repos - even though the user is a member). While the SSO option exists for "classic" access tokens, I can't find a similar authorisation option for the "fine-grained BETA" variant. Also, neither variant will allow my user to list or access repos via the API, even though the user has access through the UI.

It is essential to have Configure SSO for Fine-grained personal access tokens as it is for the classic access tokens

SSO is also important for me. I'm having trouble managing Actions caches via gh cli in a private org repo due to scope requirements that classic tokens seem to not support.

Hi, could you point in the right direction on how you were able to add the checks permission through a request.

There is a Edit and Resend option in Firefox's Network tab in the Inspector, you'll need to find your way around the parameters but it is possible.

This is disabled due to a couple edge cases right now, but I'm glad it worked for you!

Happy to hear it is on the roadmap 👍

@hpsin So, for the API endpoints that require that permission, how would one get a fine-grained PAT with the Checks permission? Is intercepting browser requests the only solution?

or even a log similar to webhook responses.

Have you checked out the webhooks for these events? https://github.blog/changelog/2023-03-24-organization-apis-for-fine-grained-pats-management/