I would like to use the Azure DevOps API to create a PAT for my user. But I'm unable to authenticate yet. In this document from Microsoft, they state that authentication is possible with a PAT, but it is not true. I'm getting a HTTP 203 with a Sign In page in response.
PS: I'm using Postman to test the API requests.
I think the security section of this REST API is misleading.
In fact, this REST API cannot be authenticated with PAT, as mentioned in another document:
To use the API, you must authenticate with an Azure AD token.
Unlike other Azure DevOps Services APIs, users must provide an Azure AD access token to use this API instead of a PAT token. Azure AD tokens are a safer authentication mechanism than using PATs. Given this API’s ability to create and revoke PATs, we want to ensure that such powerful functionality is given to allowed users only.
This document also explains how to use this REST API in detail, which you can refer to.
Yes it does work, you're just not setting it up right.
Look at the Basic Authentication of this document. You need to base 64 encode the username password like this: username:PAT. Spearate the two with the colon.
Related
I am attempting to set up an Azure B2C instance, I want to enrich the token with extra claims using an API Connector.
Can I use an Azure Function app function as the API?
I can't see anyway to do this using the Authentications allowed - the API Connector only seems to allow Basic (username/password) or Certification authentication. Whilst the Function App requires a x-functions-key in the header.
Am I heading down the wrong path with this? Should I use a simple API?
#juunas got it right in the comments.
https://<myfunctionApp>.azurewebsites.net/api/GetClaims?code=<mykey>
I want to use this method for deploying my ApiManagement Settings from a my Git repository.
https://learn.microsoft.com/en-us/rest/api/apimanagement/tenantconfiguration/deploy
But (of course) I am asked for a authorization token.
I cant figure out where to find/create this token?
There are two ways to call APIM management API. One is to go through ARM - calling URLs that start with management.azure.com. This way you're relying on Azure authentication, it's RBAC rules, and the regular wayt to authenticate to Azure apply here: https://learn.microsoft.com/en-us/rest/api/azure/#create-the-request. This is recommended way. This is the same API that is used by Azure PowerShell.
APIM does offer another way though called Direct API. This is optionally enabled in Management API page. There as well you can generate a SAS token that to can put into Authorization header while making a call. For this to work you need to call APIM API directly via .management.azure-api.net. Base URI for your service is displayed on the same page.
Is there a way with a single app to access Graph, VSTS, and Azure information? It seems access to each of these requires it's own app with origination and callback urls.
For Azure, I'm using NPM's passport-azure-ad in a node js app.
Ideally, I would like to combine VSTS build info, Azure service usage info, and User profile info.
Each of the services you mentioned has their own API:
Azure REST API
Visual Studio Team Services REST API
Microsoft Graph
This does not however mean that they also each need their own "app". When you register your application in Azure AD via the Azure Portal you're able to request access to a number APIs. Each access_token you receive will be tied to one API (called a "resource") but you can use the refresh_token to switch the targeted resource:
The only exception here is the VSTS REST API. While most APIs use the same identity provider, VSTS has their own. So for the purposes of VSTS, you will need to have the user authenticate separately. Obviously, that isn't a great user experience but there is a useful workaround: Personal Access Tokens.
Using a Personal Access Token for VSTS allows you to authenticate the user via Azure AD OAuth and get an access token you can use with Microsoft Graph and the Azure REST API. Once you've authenticated them, you can ask them to provide a Personal Access Token to access VSTS. This allows you to forgot asking the user to authenticate a second time since you'll store their PAT use it for any calls to VSTS.
First, there is Allow scripts to access OAuth token option in the Phase of Build/Release definition, you can check this option and access the token through System.AcessToken variable.
To grant the permission for that user, you need to grant the permission(s) for Project Collection Build Service (xxxx) account.
Secondly, there are some tasks related to Azure (e.g. Azure PowerShell), that can access azure resources (The AAD application is associated to the Azure endpoint)
You can retrieve the necessary information in multiple task, then store the result in the variables through Logging Commands (##vso[task.setvariable]value), then combine them together.
I was working on a JS app which talks to Azure AD app using OIDC. Here is the flow of authentication and validation -
Redirect user to common login end point
Get access token, id_token etc. on callback url
Validate response with jwt keys retrieved from discovered url - https://login.microsoftonline.com/common/discovery/keys
Get user info from discovered userinfo url - https://login.microsoftonline.com/common/openid/userinfo
Store the information in local / session storage, depending upon settings.
The problem with Azure AD is, we can not complete step 3 and 4. Both the urls do not support CORS. We are not able to validate the tokens we get and can't retrieve the user information.
Is there any better way to get userinfo in Microsoft's implementation of OpenID for Azure AD?
You are correct, Azure AD does not support CORS for either the metadata URL or the keys URL.
The general guidance is to not validate the id_token since you should only be using those claims for display purposes and not to drive any core functionality.
For core functionality (aka API calls) you should use access_tokens which should be validated by your back end which does not need CORS enabled endpoints.
You'll see these principals in action in the Azure AD SPA sample where authContext.getCachedUser() in adal.js is used to obtain the read the user and its claims without any validation.
If you want more validated user info, the guidance is to call the Graph to obtain user info via the Microsoft Graph's /me endpoint. You can see this pattern in the Azure AD Xamarin Sample.
You can vote for the request in the Azure AD feedback forum: Add CORS support for discovery and json web key set endpoints.
I ran into the same problems a while ago and the solution to these problems was to double hop the JWKS and UserInfo calls via an API.
I also used the certified and widely respected OIDC Client library, which has features for SPA silent token renewal and id token validation.
Personally I like to keep my apps coded in an Open Standards manner as much as possible, rather than being locked into one vendor.
PS. If you think this type of solution would work for you, here is a GitHib Sample and some documentation.
I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.