I am trying to implement an integration between a web-based code editor and Azure Devops. I am trying to use OAuth to get user authorization and then to make a clone of a repository on behalf of the user.
For GitHub I can use the OAuth access token as a username to clone the repository. Is there a similar functionality for Azure Devops?
Is there a similar functionality for Azure Devops?
The answer is yes.
Azure DevOps Services uses the OAuth 2.0 protocol to authorize your app for a user and generate an access token. And we need make sure Authorised scopes include code (Read) when we generate the OAuth token:
Please refer this document and this blog for some more details.
Note:
Since OAuth 2.0 is not supported on Azure DevOps Server
(I saw you add Azure DevOps Server tag on your post). Client
Libraries are a series of packages built specifically for extending
Azure DevOps Server functionality. For on-premises users, we recommend
using Client Libraries, Windows Auth, or Personal Access Tokens
(PATs) to authenticate on behalf of a user.
Related
I am building a web application where users have to provide my web application access to their repositories in GitHub| Bit bucket| Git Lab | any other code hosting platform.
I have implemented it through OAuth2 for which I had to create client applications on all platforms separately.
Initially it was scoped only to GitHub | Bit Bucket but now I want my web application to support all other major platforms as well.
So my current implementation requires me to create client applications for all other plat platforms which is a hectic because We want to give support for On-Premise version control system as well.
Is there a secure and generic way to authorize to version control system ?
One solution is that user directly provide their Personal Access Tokens (Encrypted) to my web application so that my application can save these PAT and use them to pull the repositories in future.
But I wonder if this is a secure enough or a standard method. If not then what might be the appropriate solution to this problem.
You might need to use an Oauth2 provider like:
dexidp/dex, an identity service that uses OpenID Connect to drive authentication for other apps.
Dex acts as a portal to other identity providers through "connectors", which do support your targets
or casdoor, an Identity and Access Management (IAM) / Single-Sign-On (SSO) platform with web UI supporting OAuth 2.0, including some of your targets.
Oauth2 is not the only option, as illustrated by SmartGit
After some reflection I realized that I actually haven’t had authentication problems with SmartGit and Azure DevOps for quite a while, so I spent some time experimenting to figure out just how SmartGit is authenticating to my repos in Azure DevOps.
I ultimately determined that it uses Personal Access Tokens via the Git Credential Manager.
So explicit support of PATs by SmartGit probably isn’t a critical feature after all. When you install Git (on Windows at least), you have the option to install the Git Credential Manager as well.
As long as you do that you should have smooth sailing.
I'm looking for a way to use DevOps REST API (e.g.: download artifact published from pipeline) from VSCode extension (from TypeScript/JavaScript). (That is, I'm writing the extension/code to do that...)
In VSCode there is Azure Account extension (https://github.com/microsoft/vscode-azure-account) which is used in many existing extensions interacting with Azure so I'd like to use it too to be consistent. It handles Azure sign-in and exposes credentials.
I found out there is Azure DevOps Services REST API (https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1) and Node.js client (https://github.com/microsoft/azure-devops-node-api) but it seems to use different form of authentication for Azure (personal access tokens), so I think it's not possible to use it with Azure Account extension?
Is there a way to get required credential information from Azure Account, or is there an alternative for accessing things like pipeline artifacts?
I am trying to use Microsoft Identity Platform to authorize users to access Azure DevOps REST APIs in my Angular SPA, similar to how it is done for Graph API authorization. Do I use Azure Portal and register my app and include the Azure DevOps API with user_impersonation scope?
You don't need to use Microsoft Identity Platform to access Azure DevOps REST APIs.
For angular application that want access to resources like Azure DevOps REST API's, you can click Microsoft Authentication Library for JavaScript (MSAL.js) for detailed information.
And here is a code sample.
I'm trying to set up a new instance of Aggregator CLI as an Azure function app. I've created the app on Azure and think I've installed Aggregator CLI, but don't know how to save my Azure DevOps (formerly VSTS) Personal Access Token (PAT) to Aggregator in order for the app to authenticate against DevOps. To be clear, I am not trying to install the server plugin (which requires an on-prem instance of TFS) nor am I trying to configure the webhooks version (which has been deprecated).
What I've done so far
Created a new resource group on Azure
Created a function app on Azure with storage account and application insights
Created an Azure service principle
Assigned permissions to the Azure service principle
Downloaded FunctionRuntime.zip v0.9.8 from https://github.com/tfsaggregator/aggregator-cli/releases
Deployed the code to the function app
Created a PAT in Azure DevOps
Expected behaviour
I expect to be able to save the PAT to the Aggregator_VstsToken application setting on the function app, so that the app can authenticate against VSTS. Setup.md doesn't describe how to do this. I expect to see the application settings shown in this screenshot on the app.
Actual behaviour
There isn't an application setting called Aggregator_VstsToken on the function app. There aren't any other Aggregator-specific settings either.
Environment
Azure DevOps (VSTS) cloud
Azure Function App
So I've been reading GitHub developer docs and about webhooks they have the following statement:
Webhooks allow you to build or set up GitHub Apps which subscribe to certain events on GitHub.com. When one of those events is triggered, we'll send a HTTP POST payload to the webhook's configured URL. Webhooks can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server. You're only limited by your imagination.
However, about Apps they've also got this statement:
Apps on GitHub extend and improve existing workflows. People can
purchase apps from GitHub Marketplace or browse useful tools and
services that integrate with GitHub in Works with GitHub.
If you're building or adding integrations, this documentation will
help get you up and running.
For support requests, bug reports, and discussions related to GitHub
Apps (not OAuth Apps), use the GitHub Platform Forum. The forum allows
you to collaborate with other integrators as well as engineers and
product managers from GitHub.
If your request is about OAuth Apps, or if you need to discuss a
private concern, please contact support directly.
This seems that Webhooks can only be used with GitHub Apps? The difference between GitHub Apps and GitHub OAuth Apps isn't very clear and I fail to see why an OAuth app would not be able to use Webhooks?
Edit
Can Webhooks be used with a GitHub OAuth App?
Yes.
Webhooks allow you to build or set up GitHub Apps which subscribe to certain events on GitHub.com.
This is an incorrect statement. This should be 'an integration with GitHub' rather than 'GitHub Apps'.
This seems that Webhooks can only be used with GitHub Apps?
No. GitHub Apps include implicit support for Webhooks. OAuth Applications request tokens with a scope for write:repo_hook or admin:org_hook to register a Webhook on the Repository or Organization.
There is a guide for creating webhooks that suggests to use the repo hooks or org hooks API endpoints.
The difference between GitHub Apps and GitHub OAuth Apps isn't very clear and I fail to see why an OAuth app would not be able to use Webhooks?
There is documentation that describes some differences between GitHub Apps and OAuth Apps.
TLDR advantages of GitHub Apps:
Granular Permissions
Option to use short-lived Tokens
GitHub Apps do not need to add a Webhook to a Repository or Organization
Avoids having Machine/Service Account users
Original
Webhooks allow your server/application to get notified whenever a specific event happens - regardless of whether you are using OAuth or GitHub App. Your application will then need to process an event and act accordingly.
Separately, your application will need to interact with GitHub's API to create, read, edit, or delete information. GitHub will usually require credentials to access or update specific information. Authentication to GitHub's API can use multiple methods:
None
Basic Authentication (username/password)
OAuth2 Token
Personal Access Token (PAT)
Installation Access Token
There are additional differences between legacy GitHub integrations and GitHub Apps.
Older integrations were based on Oauth2 and use a Token associated with a user's account. Integrations would interact with GitHub's API on behalf of a user - which is why some organizations would set up a machine user. Webhooks also need to be added explicitly.
GitHub Apps will interact with GitHub's API on it's own behalf. You must explicitly grant a GitHub App access to an Organization or Repository which enables both Webhook and API access.