I am trying to make an API call to Microsoft Graph using the Microsoft Logic App HTTP connector. The call fails with the error:
"BadGateway. Http request failed as there is an error getting AD OAuth token: 'Failed to extract error details from response content ''.'.".
I have been trying many things including being able to run the call successfully via Postman. I have decrypted the Postman token with jwt.ms and verified certain values such as:
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/{{tenantId}}/",
I went through stacks of Google searches, and as for Stack Exchange, these are the closest matching posts that I could find.
Http request failed as there is an error getting AD OAuth token: 'AADSTS50001: The application named https://management.azure.windows.net
In this case the audience paramater was wrong, and in my case I have tried many, and not really sure anymore which is the correct one, even though none of them worked for me when tested.
Azure Logic App HTTP action authorization fails
The post deals with a shared key use case. My current requirement for this project is to use OAuth.
Secure access and data in Azure Logic Apps
I have tried the following for "Authority":
"authority": "https://sts.windows.net/{{tenantId}}/"
"authority": "HTTPS://login.microsoftonline.com/{{tenantId}}/"
"authority": "HTTPS://login.microsoftonline.com/{{tenantId}}/oauth2/v2.0/authorize"
This is the screen that shows the HTTP connector inside the logic app.
This is the same connector at runtime.
This is the raw HTML that the HTTP connector generates.
Hoping someone can spot where I am going wrong.
http://reverse.geocoder.api.here.com/6.2/reversegeocode.json?xnlp=CL_JSMv3.0.17.0&app_id=Ca548bnNQGuB45wgmgrU&app_code=WTve4O4ccq_5ErqHb7MQfoiAJP4hLw9UmIeNvjc8s4M&mode=retrieveAddresses&maxresults=1&prox=<.....> request failed
On using the Here API with valid API key and codes, it yields an error as above. It wants to use the reverse geocode API over https, but is being loaded over HTTP.
Check out this request which results in success response.
Request using App_id and App_code
https://reverse.geocoder.api.here.com/6.2/reversegeocode.json?prox=41.8842%2C-87.6388%2C250&mode=retrieveAddresses&maxresults=1&gen=9&app_id=devportal-demo-20180625&app_code=9v2BkviRwi9Ot26kp2IysQ
Request with Api_Key
https://reverse.geocoder.ls.hereapi.com/6.2/reversegeocode.json?prox=41.8842%2C-87.6388%2C250&mode=retrieveAddresses&maxresults=1&gen=9&apiKey={}
These request using Https instead of Http.
for more details you can check this link-
https://developer.here.com/documentation/examples/rest/geocoder/reverse-geocode
I am new to Web Api 2. I am trying to build a project to explore token authorization. I created a new project in VS 2013 and selected the WebApi2 template and used Fiddler to emulate http requests. I didn't change anything in the template, just ran it as it was and tried to play with it with Fiddler. I successfully created a user by issuing request to /api/account/register but I can't login by issuing a POST request to the /Token endpoint. The request is:
http://localhost:YYYY/token?grant_type=password&password=admin123456&username=admin
(i also tried to pass the parameters as a json object in the request body).
I get back this:
{"error":"unsupported_grant_type"}
From other posts such as ASP.NET WEB API 2 OWIN Authentication unsuported grant_Type I learned that I needed to enable CORS for web api and at the token endpoint, but that hasn't worked for me.
Are you sure that you are sending POST request message and not GET?
If you simply go to the URL with query string (or open connection to this URL from your code) you are sending GET message by default. It's not what WebAPI with "/token" path is listening for.
If you are calling web service from same place, CORS is not needed. The error "unsupported_grant_type" could be in the format of the data you are passing server in post action.
Try sending with Content-Type application/x-www-form-urlencoded
We have a secured WCF service with WsHttpBinding, Client & Server certificates & transport security with Claim Based Authorization.
Everything works fine 50 % of the time. When we do request to a secure endpoint, we get the correct response. But if we send the same request again immidiatly after the first we get the following response:
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
If we then send a request again, we get normal behaviour. So the odd requests work and the even not.
But after some more investigation in the problem. We noticed that if there is at least 1:40 minutes between the previous request, we don't get the error response.
What we can confirm from the debugger and logging. The client sends the credentials to the service. We don't enter System.ServiceModel if we have the Authentication response. In the IIS trace logs we get this on a good request:
Authentication: SSL/PCT
User from token: Domain\CertifacteUserName
and this on a bad request:
Authentication: NOT_AVAILABLE
User from token:
Also in the IIS Trace logging. If we send the second request, we see that the ConnId and RawConnId are the same on both requests. And if we make multiple successful request (By allowing some time between requests) they are different for each request.
It seems to me IIS is not getting the Credentials we send, when they are there. Is this due to caching? Or something else? Does anyone has a solution.
This is a conceptual question.
I have a client (mobile) application which needs to support a login action against a RESTful web service. Because the web service is RESTful, this amounts to the client accepting a username/password from the user, verifying that username/password with the service, and then just remembering to send that username/password with all subsequent requests.
All other responses in this web service are provided in a JSON format.
The question is, when I query the web service simply to find out whether a given username/password are valid, should the web service always respond with JSON data telling me its successful or unsuccessful, or should it return HTTP 200 on good credentials and HTTP 401 on bad credentials.
The reason I ask is that some other RESTful services use 401 for bad credentials even when you're just asking if the credentials are valid. However, my understanding of 401 responses are that they represent a resource that you are not supposed to have access to without valid credentials. But the login resource SHOULD be accessible to anyone because the entire purpose of the login resource is to tell you if your credentials are valid.
Put another way, it seems to me that a request like:
myservice.com/this/is/a/user/action
should return 401 if bad credentials are provided. But a request like:
myservice.com/are/these/credentials/valid
should never return 401 because that particular URL (request) is authorized with or without valid credentials.
I'd like to hear some justified opinions one way or the other on this. What is the standard way of handling this, and is the standard way of handling this logically appropriate?
First off. 401 is the proper response code to send when a failed login has happened.
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
Your confusion about, myservice.com/are/these/credentials/valid sending back 401 when you just do a check, I think is based on the fact that doing boolean requests in REST often is wrong by the RESTful constraints. Every request should return a resource. Doing boolean questions in a RESTful service is a slippery sloop down to RPC.
Now I don't know how the services that you looked on are behaving. But a good way of solving this is to have something like an Account object, that you try to GET. If your credentials are correct, you will get the Account object, if you don't want to waste bandwidth just to do a "check" you can do a HEAD on the same resource.
An Account Object is also a nice place to store all those pesky boolean values that otherwise would be tricky to create individual resources for.
401 should be sent only when the request needs authorization header field and authorization fails. Since the Login API doesn't require authorization, hence 401 is the wrong error code in my opinion
As per the standard here https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
*10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].*
If the 401 response code is misleading for user authentication, the API can send HTTP status code 200 OK for both successful and failed authentication, but set a custom header on the authentication successful response and omit that header on failed logins.
The client can check if the header exists or not and decide the action.
Example: SpringBoot API Response
The call to OK when login is successful sets the header "gotyouin" with a value (anything). Call to failed does not add the header and client can treat this as a failed login attempt.
public class LoginResponseEntityHelper {
public static ResponseEntity<?> ok(String token) {
return ResponseEntity.status(HttpStatus.OK).header("gotyouin", token).body(null);
}
public static ResponseEntity<?> failed() {
return ResponseEntity.status(HttpStatus.OK).body(null);
}}
It is logical to use 401 http status code when access to a resource is denied because the request lacks or has incorrect credentials. And when correct credentials are provided, the request should complete successfully granting access to the protected resource.
Applicable for your case: myservice.com/this/is/a/user/action.
Maybe we should be clear about this credentials
In most secure applications, credentials are needed to access protected resource(s). These credentials can be sent along every request via HTTP header. Specifically the Authorization Header.
Therefore the Authorization header contains credentials to allow a user to access protected resource(s).
Remember that a user who was verified successfully as an authorized user(successful login), is the one given this priviledged credentials to allow for access on protected resources on the server.
From the server point of view, a HTTP request targeting a protected resource yet it is lacking credentials or containing invalid credentials may cause to validly send back 401 response code.
Therefore the Login API should not send a 401 response code because of a failed login attempt. It is misleading. Reasoning out that you are requesting to the server application via the Login API to grant you with credentials required to access resources that are protected. By itself, the Login API is not a protected resource.
So what is the correct response status?
Well I will opine towards sending back a 400 response code because a failed login attempt is a client error who is at fault for not providing the correct username or password.
According to RFC standards about 400 code:
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)
Again I will reiterate that failed login is a client error due to providing details that are incorrect. Sending back a 400 doesn't have to mean that the request syntax is malformed. But a malformed syntax is one of the reasons.
Sending a 401 would really be misleading as the user doesn't need to provide authentication information to access the login API.