The scenario is :
I have a Rest api gateway which when triggered invokes a lambda which processes the request and returns the repsonse.
This api endpoint is public.
I have another lambda which will call this API gateway/endpoint and obtain response from it.
Now the queries :
I am directly calling the invoke url of api just like any other api. So is this the right way to do so?
When I put the invoke url in browser address bar, it is giving missing authentication token.
How to actually call the url in calling lambda, i mean how to pass tokens; in Node.js ?
Thanks 😊
Well, the questions are quite wide enough. I'm trying to answer as much as possible.
First, the design you are following of Rest API -> Lambda, it is called 'Integration Type' is 'Lambda function' and use 'Use Lambda Proxy integration'.
Please take a look on the documentation here and an example here
Go through the document I believe you will understand in-out of this model. At high level, this model API Gateway is passing through request and response and you (Lambda) will handle everything.
Question 1:
I am directly calling the invoke url of api just like any other api. So is this the right way to do so?
[Answer] There is nothing wrong with this model. And yes, you can call this API (Lambda proxy) as any Rest API.
Question 2:
When I put the invoke url in browser address bar, it is giving missing authentication token
[Answer] Please check the setting of your API. As the below screen-shot, my api is using Cognito as Authorizer. It means consumers need to provide 'Token' (oAuth2 for example) when calling the API. You can use either Lambda authorizer or Cognito authroizer. It's up to you.
And if you are not requiring any authorizer, you can set it as NONE so there is no authentication token require for your API.
In short, the message you are getting now it means your API is having an 'Authorizer' and you are not sending token along with request.
Question 3:
How to actually call the url in calling lambda, i mean how to pass tokens; in Node.js ?
It is pretty common. You can google it like 'oAuth2 in Node.js', it will give you tons of examples
https://resources.infosecinstitute.com/securing-web-apis-part-ii-creating-an-api-authenticated-with-oauth-2-in-node-js/
https://stormpath.com/blog/talking-to-oauth2-services-with-nodejs
I hope it helps. Otherwise, leave your comments and questions.
Thanks,
Related
as the title already implies my RestAPI does not forward the user information of the authorized client to my lambda function. I tried with a rust lambda function (see the issue here), but it turned out, a nodejs implementation has the same problem. I have posted my cdk setup in the above issue and i bet there is a configuration mistake i made, but just cannot find.
I checked that you need to be authroized in the first place (which works, as the gateway returns "unauthorized" in that case). But whatever i tried so far, the context.identity field is always empty/null.
Any help appreciated!
I have a redirect widget that calls the AWS Lambda using AWS API Gateway. it returns a twiml-gather then will call an external API base on the output I receive on the twiml-gather
for security reasons, I would like to make my AWS API Gateway have an OAuth or API key
right now, I'm not sure how can i achieve this given that using the redirect widget doesnt have an option to input a http-headers (can't use the Twilio function because of 10 seconds time limit)
You can make use of the X-Twilio-Signature here.
You also find some Twilio blog posts on this topic.
Validating Requests are coming from Twilio
https://www.twilio.com/docs/usage/security
If your application exposes sensitive data, or is possibly mutative to your data, then you may want to be sure that the HTTP requests to your web application are indeed coming from Twilio, and not a malicious third party. To allow you this level of security, Twilio cryptographically signs its requests.
I need to authenticate a webhook post from a third party integration on my backend api server. The only thing I can define is the endpoint url they will call. It can't be dynamic once they have to register and the process takes 3 days. And we use a multi-tenant solution, so we have to authenticate with different schema on every call.
So the problem is that I have to create a filter for this webhook, so I can authenticate it through a value contained in the json of a post body.
So I defined a WebSecurityConfigurerAdapter and added a AbstractPreAuthenticatedProcessingFilter so I can intercept the request, read the value in the json body authenticated with the appropriate credentials.
I follow this tutorial Reading HttpServletRequest Multiple Times in Spring so I could be able to read InputStream from the request without erase it.
So my question about it are two.
1: Is there a better/easy approach so I can archive this result?
2: I guess this tutorial are missing something, because I'm getting null pointer at servlet when try to read the request (again, after I have already read at the filter).
Any guess would be appreciated, thanks in advance.
Are we allowed to know which 3rd party service?
PayPal/Stripe for example have docs already to explain how to verify the data.
If you can add metadata/custom fields to the webhook, you could sign it for example.
As far as checking the signature/verifying it, why not do this in the #Contoller=>#Service?
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.
I am facing this error sometimes (not always). I create a resource and a method in an API Gateway function. Then I map it to a Lambda function. On testing it there itself, everything works fine.
Now I add a custom authorization function to the method. Now, if I test it there,
If I do not provide the Authorization header, it works (since it is not deployed yet. After deployment, it would require the Auth header)
If I, however, provide the Authorization token, I get the error:
The request signature we calculated does not match the signature you
provided. Check your AWS Secret Access Key and signing method. Consult
the service documentation for details.\n\nThe Canonical String for
this request should have
been\n'POST\n/2015-03-31/functions/arn%3Aaws%3Alambda%3Aus-eas
More details: The lambda function belonging to this method was deleted. Then I re-created the function with the same name. And noticed that the method was deleted when the API was deployed. So I re-created the mapping and mapped it to the Lambda function. Since, then I am facing this issue. I am sure if I change the name of the Lambda, it might fix the issue. But I think it's a bug with AWS and not at my end. Need to clarify if there is anything I am doing wrong ?
It looks like the currently deployed version of the API is forwarding the Authorization header from the method request to the integration request (Lambda). If you are trying to fix the current state of your API, then I suggest removing the Authorization header from the method request, which will also remove it from the integration request. This should fix the Lambda signature errors.
If you're trying to use the custom authorizer on a method, you don't need to set up the Authorization header in the method request. You just need to set the authorizer identity source as 'method.request.header.Authorization'