- Prioritize Microsoft OAuth Sign in; use PAT or SSH depending on the context and rely on Git Credential Manager.
- Manage secrets securely: SecureString/Keyfile in PowerShell and secrets in GitHub Actions.
- Automate with Fabric APIs to connect, update, and commit changes, while monitoring LRO operations.
- Resolve authentication issues in Azure DevOps by correcting GCM, remotes, caches, and network configuration.

Using Git from PowerShell safely It's not just a matter of convenience; it's a requirement for protecting your code and pipelines. In scenarios involving Azure DevOps, GitHub, or Microsoft Fabric integrations, proper authentication makes the difference between a robust workflow and a vulnerable one.
In this practical and comprehensive guide We review recommended authentication methods (Microsoft OAuth, PAT, and SSH), the use of the Git Credential Manager, storage Secrets with PowerShell, secrets in GitHub Actions, automation with Fabric APIs, and troubleshooting typical Azure DevOps login issues. All with a focus on minimizing risk and improving productivity.
Authentication methods for Git: OAuth, PAT, and SSH keys
The preferred approach today For Azure Repos/Azure DevOps, use Microsoft Entra tokens based on OAuth 2.0, due to their enterprise integration and scope controls. You can also use PAT as an alternative and SSH keys where more practical or required.
- Microsoft Login OAuth Tokens (recommended): These can be obtained on demand and used with both Git and REST APIs. From the Azure CLI, you can sign in and retrieve an access token to add to your Git operations. For example, with user authentication, you can retrieve the token with
az account get-access-tokenand apply it to Git using an additional header likehttp.extraheaderwith valueAUTHORIZATION: bearer(using “bearer” and the issued token). - Personal Access Tokens (PAT): These are useful when you don’t have SSH or can’t use OAuth. They can be limited by permits and expiration, reducing exposure. To use them with HTTPS, remember that Git will ask for a username (it can be fictitious) and the password will be the PAT. If you need to send the PAT in a header or string, Base64 encoding is a common client-side practice when the workflow requires it.
- SSH keys: They work with a public/private pair generated on your machine. The public key is associated with your account (e.g. in Azure DevOps or GitHub) and the server encrypts the communication; you decrypt with the local private one that should never be shared. SSH is especially convenient if you already use the SSH agent, if you don't want to manage PAT over HTTPS or if your Linux/macOS/Windows environment (Git for Windows) fits best with keys.
Git Credential Manager: Authentication without constant typing
ECONOMY
UNSPLASH
The Git Credential Manager (GCM) Stores and issues tokens on demand so you don't have to re-authenticate for every transaction. With GCM installed, you log in once, and the manager securely stores the token (Preferred Attendance OAuth or PAT) for use with Git and other clients.
Good practices with GCM: When you change methods or detect conflicts, uninstall old credential manager configurations and reconfigure it. Then, revokes or rotates credentials when they are no longer necessary to respect the principle of least privilege.
Working with existing repositories: source, PAT, and cloning
Remove the previous remote if it was configured with an old method (e.g. username/password). You can remove the remote with git remote remove origin to avoid credential clashes before adding it again.
Re-add the remote with authentication Using PAT via HTTPS can resolve prompt issues. The remote can be expressed in a URL with the PAT embedded in the user, or GCM can be used to avoid exposing the token in text. After adding the remote, push the branches git push -u origin --all.
Cloning with Azure DevOps: The repo path in Azure DevOps includes the segment /_git/. The typical clone URL is something like this https://dev.azure.com/{organization}/{project}/_git/{repository}, Taking into account that the actual name of the repo replaces to the corresponding marker.
SSH with GitHub: Check, generate, and associate keys
GitHub allows authentication and signing commits and tags via SSH. Before adding a new key, check if you already have one registered. If not, generate a new one and add it to your system's SSH agent.
Associate the public key Enable SSH access to your GitHub.com account. If you want to use the same key for authentication and signing, you will have to charge it twice, one for each purpose. You can then reconfigure a remote to use SSH instead of HTTPS.
Automation with Microsoft Fabric: Git API Integration
- Fabric offers REST APIs for integration with Git for CI/CD and common operations: connecting workspaces, initializing connections, updating from Git, committing bulk or selective changes, and monitoring long-running operations.
- Connecting and updating a workspace: after authenticating (for example with
Connect-AzAccount) and get a token withGet-AzAccessToken, invokes the connect API to associate workspace, repository, and branch. Then, initializes the connection with the dedicated API; depending on the response, "UpdateFromGit" may be required. - Update from Git involves building the body with the remote commit and the workspace state, executing the call and probe the state of the long-running operation. The server returns an operation identifier and a retry interval, which you can check periodically until the operation completes.
- Other operations by API: Commit all workspace changes, selectively commit only certain items after checking the status, and probe LRO operations getting the operationId from the previous calls to check the progress.
- Credential connections for the Git provider: Many calls require a connectionId. You can create a new connection that store a GitHub PAT as a credential (optionally limiting it to a specific repository) or list existing connections to reuse their id. These endpoints return properties such as displayName, path, credentialType and other metadata.
- Limitations to consider: API integration inherits UI restrictions, service principal authentication is supported only for GitHub and certain semantic models may appear with diffs after improved updates.
Securely save credentials with PowerShell
PowerShell allows you to encrypt passwords and secrets and save them to disk for later consumption in scripts. With Read-Host -AsSecureString You can capture a secure credential with ConvertFrom-SecureString serialize it encrypted to a file valid only for the same user and computer.
- Use with the same user: the encrypted string saved with
ConvertFrom-SecureStringcan only decrypted by the user that generated it. To read it back in a script, applyGet-ContentyConvertTo-SecureStringto rebuild the secure object in memory. - Portable Keyfile: If you need other users or machines to be able to decrypt the secret, generate a symmetric key (for example with
RNGCryptoServiceProvider) and use it withConvertFrom-SecureString -Key. You save the key in a file and later, you rebuild the SecureStringConvertTo-SecureString -Keyusing the same keyfile. - Create a PSCredential From the secret read it is direct: you combine the user and the
SecureStringenNew-Object System.Management.Automation.PSCredential. This way you parameterize the user name and password without exposing clear text in the script. - Memory hygiene: although
SecureStringisolates the string, there are cases where you transform it to text for interoperation. If you do this, free the pointer memory withZeroFreeCoTaskMemUnicodeafter usingSecureStringToBSTRyPtrToStringUni, avoiding memory waste.
Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.