Why Azure DevOps PAT is expiring so quickly? - azure-devops

I built a project that uses PAT (Personal Access Token) generated by a user to connect to Azure DevOps REST API and get some data about a project and its commits, etc..
It happened to me twice now that the request returns with:
Access Denied: The Personal Access Token used has expired
Even though the token is not expired yet, it's been created two days ago.
Is there any limitation on using this RestAPI which if I exceeded it'll expire my token automatically?

First, you need to check with the user if the PAT has expired, because Expiration can be customized.
If the PAT confirms that it has not expired, you can try to re-create a new PAT, select All accessible organizations and Full access scope , revoke the previous PAT, and see if the new PAT is available.
In this case with the similar issue, a contributor provided a solution : the user was able to fix it by signing out and back in. This seemed to refresh the auth token and unblocked them. You can also try it .

Related

GitHub personal access token and Authenticator token

I recently created a new 'personal access token' as prompted by Github.
They deprecated the use of a password and replaced it with the personal access token on August 13, 2021 when pushing a local repository to a newly created GitHub repository.
I had to create and delete 2 other personal access tokens before my 3rd personal access token was accepted. And I am no longer prompted to enter username/personal access token now, as an email from GitHub confirmed my new PAT is associated with my GitHub account now.
But I notice in addition to my personal access token which I created in GitHub, I also see in the Authenticator app on my phone a 6 digit token is being generated. (The personal access token is very long, looks like an SHA) It is identified as connected to GitHub but GitHub hasn't prompted me to use it nor does GitHub documentation make a reference to its requirement or use. Can anyone offer some information as to why, and to what end this other token is for?
The 6-digit token you're describing sounds like a two-factor authentication token, which is used to secure your account logins to the github.com website. In contrast, the Personal Access Token is used when interacting with github via a command line interface.
To see the 6-digit code being used in action, try opening a Private/Incognito browser tab and logging into github.com. After entering your username and password, the site should prompt you to enter that 6-digit rotating code as a second factor to secure your account.
See the GitHub documentation for two-factor authentication here.

PAT Token isn't working on 2019 OnPrem Azure DevOps

I am having an issue getting my OnPrem Azure DevOps 2019 Server to allow things to authenticate to it with Personal Access Tokens (PAT). No mater what I do, I get failed to authenticate using the supplied token.
How I am creating my token:
Log into my OnPrem devops site
Go to my user profile icon in the top right, click security click personal access tokens, click new token
In Create new personal access toekn for some reasobn the organization (colleciton) I want to use is not listed, I am seeing an old XML based collection but not my new Inheritance based collection, why doesn't the newer format collection show up? My user account is an admin account, you'd think it would be here?
If I create a PAT token for the old XML based collection and give it full access plus a 90 day expiration it creates it fine
Now I have a PAT token bases off the old XML based collection, but that still doesn't work, if I run the AZ CLI I get this
AZ DEVOPS LOGIN --organization https://tfs.mydomain.com/OldXmlCollection --verbose
Token: {paste in token}
Creating connection with personal access token.
Failed to authenticate using the supplied token.
Command ran in 6.385 seconds (init: 0.167, invoke 6.12)
I also have the same problem if I try to set up a build agent using a PAT token. Fails every time, but if I change to negotiate auth it works immediately.
On the IIS end the service is running on the authentication is set up to Anonymous Authentication: Enabled, ASPS.NET Impersonation: Disabled, Basic Authentication: Enabled, Digest and Forms: Disabled and Windows Authentication: Enabled
any ideas what I am doing wrong, what to look at?
PAT Token isn't working on 2019 OnPrem Azure DevOps
You could try to disable IIS Basic Authentication.
That because when IIS Basic Authentication is enabled on your windows machine, it prevents you from using personal access tokens (PATs) as an authentication mechanism.
Please check this document Enabling IIS Basic Authentication invalidates using Personal Access Tokens for some more details.
What it turned out to be is a missing ACL in the file system. The service account that is running TFS needs to have write permission to the machine keys folder at %ProgramData%\Microsoft\Crypto\RSA\MachineKeys
Why in the world is the installer not setting this permission? PAT will not work until this is set

what permission PAT needs to access https://analytics.dev.azure.com/ExtensionTestVee/TestProjectNOBR/_odata/v2.0//WorkItemSnapshot? API

I used https://analytics.dev.azure.com/{orgname}/{ProjectName}/_odata/v2.0/WorkItemSnapshot REST API to fetch the active bug counts for past 60 days for the project in Azure devops. On using the custom scoped PAT to invoke the above API it threw unauthorized exception. Could you please tell me what permissions do I need to grant for PAT to access the workItemssnapshot API.
To use OData API to query work items in a project, you should have the following permissions at least:
On organization, your access level should be Basic.
In project, you should be a member of the project, and at least have Readers permissions. Make sure the permission View analytics is Allow for you.
For your personal access token (PAT), it should have the scopes Analytics(Read) and Work Items(Read).

Azure DevOps Artifacts/Connect to feed/Python credentials expiration

We host python packages on Azure DevOps and to make them accessible to users a pip.ini file is created on user's machine where we place a token generated from Artifacts / Connect to feed / Python / Generate Python credentials.
It was observed that with some time credentials stop working.
Does credentials expire? We didn't find anywhere in the documentation after which period of time the credentials expire.
Is it possible to control credentials lifetime (e.g. increase it)?
The python credential generate in a feed is a base64 encoded JWT(JSON Web Token ). The expiration time is defined when the JWT token is generated. I don't see there is a way to expand the token, you need to generate a new token when it is expired.
If you want to find your specific expiration time, you can copy the python credentials from the ‘pip.conf’ or ‘pip.ini’ file to this link: https://jwt.io/, which will help you find your expiration time. And your python credentials in your pip.conf is between 'https://xxx:' and '#xxxx.dev.azure.com'. All the details can be found in the screenshot. You can refer to this part from this case. Hope this will help you.
Finally I've found answers to both my questions.
Credentials do expire and default expiration period is 3 months.
It is possible to increase (or decrease) expiration period even after credentials have been already generated. I've discovered that every time I navigate to Artifacts / Connect to feed / Python and click on "Generate Python credentials" link a new credentials are generated and they can be found by clicking on user icon (top-right) choosing "Security" and then "Personal access tokens". Here you can see all generated tokens, you can Revoke them or edit. When editing you can change Expiration - the maximum duration is 1 year.

Token to Read Code from a Single Repository

Is it possible to create a token for read-only access to a single repository within VisualStudio.com Team Services?
I see I can use a Personal Access Token to limit access to a Team Services Server, but it appears to be for the entire server rather than a single repository.
Surely, there must be a way to do this.
There isn’t the Token for a Single Repository level, but Personal Access Token permission is based on the user who created.
So, you can refer to these steps below to generate a personal access token for your requirement:
Add an additional user to your VSTS instance
Logon your VSTS with that account and create a Personal Access Token.
Logon your VSTS with your own account and remove some permissions for that account (e.g. just grant necessary permission for a repository)
After that, this Personal Access Token can just access a Single Repository