AZIdentity

Something that I've seen a bunch of times in Key Vault support cases is that the customer tries to use a token previously obtained to perform operations on Azure Services such as VMs, Websites, and even Key Vault to also access keys, secrets or certificates inside the Key Vault.  They get understandably confused because the requests made about the Key Vault work fine. It's just that the requests made for Key Vault values fail with 401.

Azure's OAUTH client credentials grant protocol requires that the resource of the Web API being used is passed to the authentication server.  The documentation states this:

This is the POST sample in the same documentation:

POST /contoso.com/oauth2/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=625bc9f6-3bf6-4b6d-94ba-e97cf07a22de&client_secret=qkDwDJlDfig2IpeuUZYKH1Wb8q1V0ju6sILxQQqhJ+s=&resource=https%3A%2F%2Fservice.contoso.com%2F

The highlighted area above is what I am referring to for this issue.  There are multiple resources in Azure; here are a few that I am aware of:
 

Here is an actual OAUTH request I made using the Key Vault resource URI (with some values removed):

POST https://login.microsoftonline.com/<tenant removed>/oauth2/token HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Host: login.microsoftonline.com
Content-Length: 182
Expect: 100-continue

resource=https%3a%2f%2fvault.azure.net&client_id=<removed>&client_secret=<removed>&grant_type=client_credentials

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: 1c4a97a5-00f5-4d32-bbc2-4be61201c201
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: fpc=AXuxcQCE2KRImJ4RCkjegB_EqXEQAQDjhy1f3lbWCA; expires=Sun, 30-Dec-2018 16:10:39 GMT; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=013; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
Date: Fri, 30 Nov 2018 16:10:39 GMT
Content-Length: 1324

{"token_type":"Bearer","expires_in":"3600","ext_expires_in":"3600","expires_on":"1543597839","not_before":"1543593939","resource":"https://vault.azure.net","access_token":"<removed>"}

You can also see this value in the access token when it's decoded:

It's important to note that the resource value does not have a trailing slash!  There are other resource URIs that work fine either with or without the trailing slash, but the Key Vault resource URI does not work with it.

Why are there two Resource URIs for Key Vault?

It's because Key Vault has two different sets of resources which it uses:  the Management Plane and the Data Plane.

The Management plane is the set of operations which are performed on the Key Vault itself, such as:

• Creating/changing access policies
• Creating a new Key Vault
• Adding IP restrictions/VNet
• Setting Tags
• Access Control
• etc

Access to ARM APIs for Key Vault are set by RBAC.

The Data plane is the set of operations which allows others to retrieve/set the values of objects contained inside the Key Vault:

• Keys
• Secrets
• Certificates
• Storage Objects

These objects are governed by the Access Policies, and therefore require a different set of APIs than the Management APIs.

I hope this clears up any confusion about making calls to the Key Vault using REST. 

I hope this helps you out when using the Azure Key Vault!  Please follow us on Twitter and tweet about it!
@WinDevMatt @AzIdentity