[Feedback tracking] Fine-grained personal access tokens #36441
-
|
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:
Recently, we've added:
There are also some APIs that do not yet support the fine-grained permission model, that we'll be adding support for in time:
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! |
Beta Was this translation helpful? Give feedback.
Replies: 219 comments 360 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 For this. Is it possible to require SSH Certificates and use Fine Grained access tokens? |
Beta Was this translation helpful? Give feedback.
-
|
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)? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hello mate |
Beta Was this translation helpful? Give feedback.
-
__ |
Beta Was this translation helpful? Give feedback.
-
|
Will there be a way to create tokens that don't expire for CI? |
Beta Was this translation helpful? Give feedback.
-
|
Ignoring the lack of tooling for automation for now, better manual tools would help with FGPAT rotation. |
Beta Was this translation helpful? Give feedback.
-
|
The mandatory expiration is what's preventing me from using FGPAT. I'd like to use them to give my personal website (which gets updated every blue moon) access to a private repo that contains the code for the site. I'm sure I'll forget to renew the token (if not next year, then the year after), will have forgotten about the intricacies of the setup, and then spend hours debugging why changes don't get deployed after a year. Happy to hear suggestions for a better workflow for this use case. And no, "create a reminder in your calendar, then renew the token and update your web server configuration in 11.5 months" doesn't qualify as one. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I keep creating classic tokens because of this 🤦 I want to use the new fine-grained tokens but for CI I cannot update the CI every year, that makes no sense! |
Beta Was this translation helpful? Give feedback.
-
|
Today we've lifted the 366 day requirement for fine-grained PATs. The restriction remains in place for orgs and enterprises, but you can now create infinite lifespan tokens for your personal projects https://github.com/orgs/community/discussions/141929 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I'm using https://github.com/martinbaillie/vault-plugin-secrets-github - it works really well. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+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. |
Beta Was this translation helpful? Give feedback.
-
|
At least allow the same token to be renewed (even if already expired) rather than regenerating it. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah this is worthless without a "No Expiration" option. I can't be having my tools randomly stop working because their tokens expire. |
Beta Was this translation helpful? Give feedback.
-
|
Today we've lifted the 366 day requirement for fine-grained PATs. The restriction remains in place for orgs and enterprises, but you can now create infinite lifespan tokens for your personal projects https://github.com/orgs/community/discussions/141929 |
Beta Was this translation helpful? Give feedback.
-
|
In order to facilitate transitioning between classic PATs and fine-grained, will it be possible to enable classic PAT functionality for specific users, but disable them for all others? It makes the transition a lot more manageable from a security perspective if organizations could disable classic PATs for standard users, but keep them enabled for users that have tokens created that are integrated into automated systems that will take time to migrate. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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! |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Good to know, thanks! Who do these go out to? The token creator, repo / org owner, or both? Is it somehow configurable? |
Beta Was this translation helpful? Give feedback.
-
These go out to the token owner not the organization.
Currently not. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the info! |
Beta Was this translation helpful? Give feedback.
-
|
Y'all are hacking me |
Beta Was this translation helpful? Give feedback.
-
|
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". |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
So sorry you hit this issue! We're removing the Packages permission until it's better supported. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
according to https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/
However on the organization page, this seems to be a mismatch? am I reading this wrong? |
Beta Was this translation helpful? Give feedback.
-
|
ah, that section is only regarding the approval and auditing the "Get Started" tells that the feature is disabled for all organizations by default |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Will be nice to have source IP restriction on GH token similar to AWS IAM Roles (https://aws.amazon.com/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Please clarify |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I like this idea! All I really need is to tell GitHub to put a fine-grained PAT into the environmental variable 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. |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
At least allow the same token to be renewed (even if already expired) rather than regenerating it. |
Beta Was this translation helpful? Give feedback.
-
|
A missing feature for me is being able to authenticate against GitHub packages. Currently (buried in the docs for packages):
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 ☝️ 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! 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
This is being removed until we have support from Packages for fine-grained PATs, sorry about the confusion here! |
Beta Was this translation helpful? Give feedback.
-
|
No worries, thanks for the fast response! It's still the first few days of beta! 😄 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
Does this mean that the fine-grained PATs can also be used (in the future) with packages using native clients, like |
Beta Was this translation helpful? Give feedback.
-
|
@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! |
Beta Was this translation helpful? Give feedback.
-
|
@hpsin Any update on support of Packages? This is a pretty significant piece of missing functionality. It prevents my org from using Packages altogether. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, PS Am I "blind" to find and it is in place? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @hpsin |
Beta Was this translation helpful? Give feedback.
-
|
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 (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.) |
Beta Was this translation helpful? Give feedback.
-
Their terms of service only allow a single machine account per person/legal entity which I wouldn't say is generally enough. |
Beta Was this translation helpful? Give feedback.
-
We generally use GitHub App credentials to get an installation token, or write our workflows with |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
Seems like a great feature! However, I can't seem to generate a token which accesses specific repositories? Not sure if I'm totally missing something here. |
Beta Was this translation helpful? Give feedback.
-
|
I don't see that option, either. If it helps, I'm not a member of any public repos. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Will there be a way to associate fine-grained token with team? For example, I am a member of some teams named |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
It is essential to have |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
SSO is also important for me. I'm having trouble managing Actions caches via |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Do I see it correctly that as of today, the projects permission can only be selected for resources owned by an organization, but not a personal account, is that right? So for a personal account, you still need a classic PAT to interact with projects? |
Beta Was this translation helpful? Give feedback.
-
|
It's not clear what permissions are required for GraphQL queries because all of the fine-grained PAT documentation points to REST endpoints. I’ve got a GraphQL query (using
The PAT is scoped to a specific repository ( The queryquery GetViewerStargazers($cursor: String) {
viewer {
login
starredRepositories(first: 100, after: $cursor) {
isOverLimit
totalCount
pageInfo { endCursor hasNextPage }
edges {
node {
archivedAt
description
forkCount
homepageUrl
url
isFork
isPrivate
isTemplate
languages(first: 5, orderBy: { direction: DESC, field: SIZE }) {
edges {
node {
name
}
size
}
totalCount
totalSize
}
latestRelease { name publishedAt }
licenseInfo { nickname spdxId }
nameWithOwner
parent { nameWithOwner }
pushedAt
repositoryTopics(first: 20) {
totalCount
nodes {
topic { name }
url
}
}
stargazerCount
}
starredAt
}
}
}
}The response: {
response: {
url: 'https://api.github.com/graphql',
status: 502,
headers: {
'access-control-allow-origin': '*',
'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset',
'content-type': 'application/json',
date: 'Mon, 21 Oct 2024 17:04:24 GMT',
server: 'github.com',
'transfer-encoding': 'chunked',
vary: 'Accept-Encoding, Accept, X-Requested-With',
'x-github-request-id': 'E238:17113B:3A205E:6F5559:6716898E'
},
data: { data: null, errors: [Array] }
}If this is a permissions error, it could be a lot clearer. (It's also not clear to me where this error should be reported.) |
Beta Was this translation helpful? Give feedback.
-
|
I've encountered this when making a query that would result in a very large response. If you reduce the number of repositories to, say, 10, does the error disappear? I 100% agree that the error is super confusing, because to me 502 means that I didn't do anything wrong. |
Beta Was this translation helpful? Give feedback.
-
|
I would expect that to be required under the classic PAT, but it is not (the requests succeed with the classic PAT and fail with the fine-grained PAT). I’ll try it, but I’m not expecting anything useful to result from it. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, interesting, I'll try my query with a classic PAT as well to see if it stops breaking for large responses! |
Beta Was this translation helpful? Give feedback.
-
|
I dropped the repositories per page to 20 and it appears to have worked, but it's taking substantially longer to execute (this is unsurprising, but the scale is); this might be something in the GraphQL API restricting the computed complexity of the response (the error is really bad if that's the case). I’ll need to play with larger numbers because it looks like the PAT took ~6x longer to execute. |
Beta Was this translation helpful? Give feedback.
-
|
Any chance we can have fine-grained tokens for only selected gists? |
Beta Was this translation helpful? Give feedback.
-
|
Every time I need to dig up my projects I struggle with tokens. There is a too long list of irrelevant features, but no feature just to fetch and push new changes. Can you make a simple button or a guide for minimal list of requirements for token to be able to clone a project and push some changes to it for dummies like me? |
Beta Was this translation helpful? Give feedback.
-
|
Re That doesn't look promising. I was just looking into this yesterday as I wanted to access a package in my personal account but don't want to create a token that has access to other organizations that I'm a member of (like e.g. my employer). Not being able to create even an organization-scoped token to access packages makes packages/ghcr.io unusable if you use organizations and care about security. @ankneis do we have any hope of a solution to this, given the seeming de-prioritization? |
Beta Was this translation helpful? Give feedback.
-
|
There is a response to this question from @hpsin a few months ago: https://github.com/orgs/community/discussions/36441#discussioncomment-10477883 (I asked the same question) If you are paying for Github, you can always write to support and ask them to put your feedback/wish for this feature in. Any company will prioritize feedback from paying customers over anonymous wishes on a forum 😄 |
Beta Was this translation helpful? Give feedback.
-
###- [x] @nbibler # |
Beta Was this translation helpful? Give feedback.
-
|
Hi team, Could we support form pre-filling with the new personal access token? E.g., https://github.com/settings/personal-access-tokens/new?name=new-token&description=token&scope=... It's possible via classic token: https://dev.to/dakdevs/conveniently-link-to-a-pre-filled-new-github-personal-access-token-page-dn My use-case is I'm building an app that requires a user to create a GitHub token and I don't want them to choose the wrong scopes. They'll run into errors otherwise. |
Beta Was this translation helpful? Give feedback.
-
|
+1, @aidando73 did you find any solution for this? |
Beta Was this translation helpful? Give feedback.
-
|
+1 This would be awesome for my app as well!! |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
I am owner and I CANNOT create new access token just no 'Add', documentation plain wrong... fix it... |
Beta Was this translation helpful? Give feedback.
-
|
Try now, with the GA? It likely wasn't enabled for your org, but should be now. |
Beta Was this translation helpful? Give feedback.
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Hey folks - last week we announced the GA of the fine-grained PATs platform. As part of this GA, we've enabled fine-grained PATs for all organizations and enterprises that did not explicitly disable it during the preview. As a result, within 24 hours of the ship we've seen a dramatic drop in the number of infinite-lifetime tokens being created - thank you for all of your feedback and reports, you've helped everyone get to a more secure developer workflow. We know there's still more work to go before you can use a fine-grained PAT for everything. First up is the ability to call Enterprise account APIs (SCIM, e.g.). You'll find that and more in the public roadmap and detailed in our documentation. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the update @hpsin 😃 |
Beta Was this translation helpful? Give feedback.
-
|
@hpsin Any update on the ability to query what scopes a fine-grained PAT has? I need this for something I'm working on. See https://github.com/orgs/community/discussions/156115 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Once a repository has been added to a fine-grained PAT, there is currently no way to remove it, even if it was added by mistake or the repo has since been archived? |
Beta Was this translation helpful? Give feedback.
-
|
Hello,
Actually I have the exact same problem except that instead I would like to add repositories to its access list (the Do you think this could come back or are we supposed to create tokens for each new repository? (and running the risk of hitting the limit) |
Beta Was this translation helpful? Give feedback.
-
|
It looks like we can Edit the list or repositories again now (adding or removing some) 👍 |
Beta Was this translation helpful? Give feedback.
-
|
No anything about making it available,or updetes not 😭
در تاریخ سهشنبه ۲۵ مارس ۲۰۲۵، ۲۲:۳۱ Hirsch Singhal <
***@***.***> نوشت:
… Hey folks - last week we announced the GA of the fine-grained PATs
platform
<https://github.blog/changelog/2025-03-18-fine-grained-pats-are-now-generally-available/>.
As part of this GA, we've enabled fine-grained PATs for all organizations
and enterprises that did not explicitly disable it during the preview.
As a result, within 24 hours of the ship we've seen a dramatic drop in the
number of infinite-lifetime tokens being created - thank you for all of
your feedback and reports, you've helped everyone get to a more secure
developer workflow.
We know there's still more work to go before you can use a fine-grained
PAT for everything. First up is the ability to call Enterprise account APIs
(SCIM, e.g.). You'll find that and more in the public roadmap and detailed
in our documentation.
—
Reply to this email directly, view it on GitHub
<#36441 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMZ4UAJ7DYWEYH2XWRSSKED2WGRYRAVCNFSM6AAAAAARHG7TYGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRRHE2DKOA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
لطفا توکن ایجاد کنید من دسترسی به چندتا از مخزن هام رو کلی از دست دادم و
تازه دارم چک میکنم اسکرین شات ها و اسنادم رو میبینم چقدر برداشت داشتن از
حسابم 😭😭😭
در تاریخ پنجشنبه ۵ ژوئن ۲۰۲۵، ۱۶:۲۱ Christophe Muller <
***@***.***> نوشت:
… Hello,
Once a repository has been added to a fine-grained PAT, there is currently
no way to remove it
Actually I have the exact same problem except that instead I would like to
*add* repositories to its access list (the Repository Access section) and
before the GA I could do this: when selecting a fine-grained token in front
of the token name there was an Edit button which allowed me to change its
settings and the list of access.
Do you think this could come back or are we supposed to create tokens for
each new repository? (and running the risk of hitting the limit)
—
Reply to this email directly, view it on GitHub
<#36441 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMZ4UAKPUNTJJKXJGWF23533CA4L7AVCNFSM6AAAAAARHG7TYGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZXHE2TAMI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hi team! Are there plans to add API to check the permissions of fine-grained PATs? I ask my users for PATs and it would improve the security a lot if I could invalidate overly broad tokens! Thank you! |
Beta Was this translation helpful? Give feedback.
Hey folks - last week we announced the GA of the fine-grained PATs platform. As part of this GA, we've enabled fine-grained PATs for all organizations and enterprises that did not explicitly disable it during the preview.
As a result, within 24 hours of the ship we've seen a dramatic drop in the number of infinite-lifetime tokens being created - thank you for all of your feedback and reports, you've helped everyone get to a more secure developer workflow.
We know there's still more work to go before you can use a fine-grained PAT for everything. First up is the ability to call Enterprise account APIs (SCIM, e.g.). You'll find that and more in the public roadmap and detailed in our documen…