It's my understanding that the isCancellationRequested property of the cancellation token should be true when passing in a token from the API call.
I'm not sure if my assumption is incorrect or if it's something in the implementation of the endpoint or API call?
Controller:
Axios POST request
Related
My LogicApp A will call Salesforce API. Before calling the API, it should call the Salesforce Token endpoint with grant_type=password to fetch the access_token. The token will be valid for 1 hour. Next time my Logic App A is called by consumer, it will first check the cache for the token and if received will fetch the token from cache and then invoke Salesforce with the Authorization Bearer <access_token>. If not found in cache, it will call the Salesforce OAuth Access Token endpoint and get the token and again store into cache and subsequently passed on to the next API call. Is there any lead to how to do this in Logic Apps ?
I am building a WebApi for external consumers. I want to lock it down using Azure AD B2C token authentication. .NET Framework 4.7.2 using Owin middleware.
The workflow (as I understand it) goes like this:
Successful path:
GET request on secure endpoint, contains a header with a valid auth token
API returns expected result
Invalid/missing token path:
GET request on secure endpoint, contains an invalid/missing token in the header(s)
API returns 401
This all looks correct from a security point of view, but my poor consumers won't know how to get a new token. Should I be returning something with the 401 to assist in them getting a new token? (i.e. the URL for the Azure AD B2C endpoint) - does this break conventional rules on returning objects with a 401? Am I expecting too much for my consumers to know how to interact with my chosen 3rd-party auth provider?
My question is more about design but would appreciate any technical examples.
I have a single tenant scenario in Azure Active Directory where an API1 needs to call another API2 using authentication, and where the API1 was called from a SPA.
Would it be correct to just pass on the user's JWT received in API1 from the SPA to call API2 for authentication?
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
TokenValidationParameters = new TokenValidationParameters() {
SaveSigninToken = true,
...
like in: https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof
All APIs are implemented with ASP.NET Web API and the SPA using Active Directory Authentication Library (ADAL) for JavaScript.
Passing the token you got from the first step would NOT be correct for the second step. Every access token has a specific audience that the token is intended for, and because API 1 and API 2 are different, the audience value of that token can only match one of the two.
You link to the correct sample, which is the On-Behalf-Of flow. This flow allows API 1 to exchange the first token for a brand new token where the client becomes API 1 and the resource becomes API 2.
You can find a description of the protocol here
// line breaks for legibility only
POST /oauth2/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_secret=0Y1W%2BY3yYb3d9N8vSjvm8WrGzVZaAaHbHHcGbcgG%2BoI%3D
&resource=https%3A%2F%2Fgraph.windows.net
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2Rkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tLzE5MjNmODYyLWU2ZGMtNDFhMy04MWRhLTgwMmJhZTAwYWY2ZCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLCJpYXQiOjE0OTM0MjMxNTIsIm5iZiI6MTQ5MzQyMzE1MiwiZXhwIjoxNDkzNDY2NjUyLCJhY3IiOiIxIiwiYWlvIjoiWTJaZ1lCRFF2aTlVZEc0LzM0L3dpQndqbjhYeVp4YmR1TFhmVE1QeG8yYlN2elgreHBVQSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiJiMzE1MDA3OS03YmViLTQxN2YtYTA2YS0zZmRjNzhjMzI1NDUiLCJhcHBpZGFjciI6IjAiLCJlX2V4cCI6MzAyNDAwLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidmVyIjoiMS4wIn0.R-Ke-XO7lK0r5uLwxB8g5CrcPAwRln5SccJCfEjU6IUqpqcjWcDzeDdNOySiVPDU_ZU5knJmzRCF8fcjFtPsaA4R7vdIEbDuOur15FXSvE8FvVSjP_49OH6hBYqoSUAslN3FMfbO6Z8YfCIY4tSOB2I6ahQ_x4ZWFWglC3w5mK-_4iX81bqi95eV4RUKefUuHhQDXtWhrSgIEC0YiluMvA4TnaJdLq_tWXIc4_Tq_KfpkvI004ONKgU7EAMEr1wZ4aDcJV2yf22gQ1sCSig6EGSTmmzDuEPsYiyd4NhidRZJP4HiiQh-hePBQsgcSgYGvz9wC6n57ufYKh2wm_Ti3Q
&requested_token_use=on_behalf_of
&scope=openid
I've got a site based Web App which authenticates users via AAD login. A successful login will redirect the user back to the app with the access token (this part is all done using adal_angular.js/adal.js)
The token is then passed to a site based api which gets a new token on behalf of the user to call a downstream api as per this example (https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof) So far so good.
The downstream api, repeats this process to get another token to call another api further downstream. Here is where the problem is.
When calling AcquireTokenAsync() here, I get no response from the call whatsoever.
*Edit: No response means that I get no response from Azure AAD, using Fiddler to trace the HTTP traffic, I'm not seeing any URLs being hit as part of the AcquireTokenAsync call *
I noticed that the token I'm using at this point is now a "user_impersonation" token, where as the token received by the site based api is not. Is this significant?
Should this architecture be supported?
Ok, the problem here was my own use of async methods in my webapi. If you are calling async methods in your webapi, you need to mark your own web api methods as async. If ASP.Net doesn't know that you want to call async methods in your controller, it can cause deadlocks. (A good explanation here: http://blog.stephencleary.com/2012/07/dont-block-o...
You should never use .Result on your async methods in a web api.
When I overrode "MatchEndpoint", all I find is that a call to a method that was decorated with [Authorize] showed up with "IsAuthorizeEndpoint" and "IsTokenEndpoint" both set to false. The latter makes sense to me, the former does not.
As a result I keep getting "Authorization has been denied for this request." message. The token endpoint works correctly I can retrieve the token which I pass as bearer in the authorization header in the call to protected Api.
I am using OWIN middle ware in an asp.net webapi 2.0 with JWT mechanism
Can you guys point out what can be the possible reasons for this ?