Authentication through Personal Access Token creates organisational coupling
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- azure, python
- Domain
- api, authentication, cloud
Research direction
Start by reviewing the library's documented Personal Access Token authentication and Azure DevOps Server's supported OAuth2 or application authentication flows. Compare the H2M and M2M requirements, then define the supported flow, credential lifecycle, and documentation or tests needed to demonstrate completion.
Written by the indexing model from the issue text.
Description
Currently, the only documented way to use this library is to authenticate with a Personal Access Token.
This seems wrong, as:
- From what I know about them, Personal Access Tokens are associated to human accounts
This means an application access to an Azure DevOps instance is tightly coupled to the existence of a human person in an organisation, which means applications access will break depending on other life cycles. - Personal Access Token also require an expiration date, meaning applications access will break regularly, forcing some manual (human) extra credentials management on top of, and separate from, the one associated with the parent account.
Is there a plan to support other kinds of authentication scheme with Azure DevOps (Server)?
One could think of an OAuth2 process, for instance, allowing different flows:
- H2M, much like what is achieved through PAT, without any extra (token, on top of account), manual, token lifecycle management
- M2M which would allow managing applications-specific secrets
Both flow isolate authentication of the application from any other organisational resource, and allow delegation of authorisation and grants lifecycle to a dedicated, potentially automated third-party.
- Dominant language
- Python
- Stars
- 684
- Forks
- 218
- Avg merge
- 8d 10h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/azure-devops-python-api
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 1/5 Under an hour Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
All issues in microsoft/azure-devops-python-api
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
learningequality/ricecooker#747 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
run-llama/llama_index#23199 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
KhronosGroup/glTF-Blender-IO#2769 ·