0
votes

Following on from this question: AADSTS50013: Assertion audience claim does not match the required value

I've now successfully got the web apps running with this security model: SPA application using adal.js/adal_angular.js to authenticate via AAD. Returned token is passed to web api [API1] that runs on the same machine. That web api gets a new token on behalf of the user to access a downstream API [API2].

The downstream api gets a new token on behalf of the user to access another downstream API [API3].

Now, when I have [API2] running locally, this is all working.
However, when I deploy that web app to my Azure subscription, and attempt to call it (without changing anything else other than the url in the REST API call from [API1]), I get the following:

{"Message":"Authorization has been denied for this request."}

There doesn't appear to be any other error details returned or in the Fiddler trace. Comparing the jwt token payloads between the call that works and the one that doesn't, doesn't reveal much. They appear the same other than the expiry claims and the "aio" (not sure what that is).

The only change is the URL of the deployed web app (from http://localhost:8080/ to http://mywebappname.azurewebsites.net/)

Note that the web app is deployed into a different AD tenant to the one where the app registrations and [API3] are located, but I didn't think this mattered.

Any thoughts out there on what I might need to change when I deploy, or how to troubleshoot this further?

Update: Request works with Curl

Making the same request using curl is working:

curl -H "Authorization: Bearer ey..." http://mywebapi.azurewebsites.net/api/resource

So the issue appears to be how I'm making the request in my C# code? Comparing the headers in Fiddler, I don't see any difference. This is the Fiddler trace from curl that is working:

GET http://mywebapi.azurewebsites.net/api/resource HTTP/1.1
Host: mywebapi.azurewebsites.net
User-Agent: curl/7.46.0
Accept: */*
Connection: Keep-Alive
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJ<snip>

This is the Fiddler trace from my code that is not working:

GET http://mywebapi.azurewebsites.net/api/resource HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJ<snip>
Accept: */*
User-Agent: RestSharp/100.0.0.0
Host: mywebapi.azurewebsites.net
Accept-Encoding: gzip, deflate

Here is the request from C#:

var restClient = new RestClient(serviceUrl) { Timeout = timeout};
var restRequest = new RestRequest(apiEndpoint, Method.GET);
var bearerToken = $"Bearer {securityToken}";
restRequest.AddParameter("Authorization", bearerToken, ParameterType.HttpHeader);
var response = restClient.Execute(restRequest);

On the Azure web site logs, I can see that the authentication type for the successful curl request is "JWT", however for the failed requests from my code they are "anonymous". Somehow the header must be being stripped despite it showing up correctly in the Fiddler trace? Is this possible?

1
Since you mentioned that the two tenants, which tenant the users from you were trying sign-in?Fei Xue - MSFT
The user belongs to the tenant [T1] where the app registrations have been created. The web app has been deployed to a different azure subscription, however the valid audience and tenant configured in startup_auth.cs are still configured to use the tenant and audience for the app registration in T1.gooram
Did you enable the authentication/authorization for the apps you deploy on Azure portal?Fei Xue - MSFT
Not initially, but I tried with it turned on and it didn't appear to make a difference. Should this be on or off, and if on, how should it be configured? e.g. Token Store?gooram
It should be off. Since you have complete the authentication in the code, it shouldn't use the authentication/authorization feature again. I also suggest that you get the detail exception by enabling the logs.Fei Xue - MSFT

1 Answers

0
votes

In an unrelated issue, I had to delete all untrusted certificates from my machine (Internet Options->Content->Certificates). And I noticed after doing this, my problem was resolved. It was a very long list of certificates, so I don't know which one(s) were causing the problem, or why.
Given the lack of responses, its obviously a very obscure issue, but unfortunately we didn't get to the bottom of it. If it occurs again, I can be a bit more methodical when I do it.