Whenever I begin to use the AWS_IAM authorizer on my function, my API GET request - which is being made from a web client - receives a No 'Access-Control-Allow-Origin' header is present on the requested resource. and I'm getting a 403 status code. When I remove the aws_iam authorizer, the API request - made via the same web client - succeeds. So I'm pretty sure it's not actually a CORS error since I've double checked that my API has cors enabled. I'm not sure if I'm using the AWS Javascript SDK wrong or if I'm not generating proper roles for AWS_IAM in my serverless.yml config.
When I run the request from postman with my personal access keys from AWS, the request succeeds. When I console.log the keys from the AWS.config.credentials and use those in postman, the request receives an invalid token error message. Maybe I haven't generated the proper role for my federated identity pool?
I'm using aws4 on the front-end to sign the request, and I use axios to make the request.
Any ideas?
Axios will make a pre-flight request. It's an OPTIONS type and expects a 200 response before it will make the GET request. It also needs to return the CORS header:
Access-Control-Allow-Origin: *
Postman won't make the same call automatically but you can use it to test that request. Ensure that your API is accepting OPTIONS request methods for that route and that it returns an empty 200 response with the CORS header and I think you'll be good to go.
AFAIK, the OPTIONS request needn't be authenticated. Just give a green light. It may be the case that your client is making calls to this endpoint as OPTIONS requests that are being authenticated, adding a second layer of confusion, or you may need to add an Access-Control-Allow-Headers to allow an Authorisation type header if AWS is using one.
Hard to give more information without debugging but I would start with an OPTIONS request.
Related
I am using AWS Cognito federated through Google.
I am trying to use the Authorization Code Grant flow, which requires making two requests.
/oauth2/auth
The first request is to get the authorization code, which is then sent as part of the second request. This request comes back fine.
/oauth2/token
This request accepts the authorization code from the first, and should return the appropriate tokens.
However, this endpoint requires a secret in the header, so I have created an API (to not expose the secret to the client) that accepts the token and makes the request from a different origin as the first request. For example, the first request is made from example.com, while the second is from api.example.com. This fails with the error message: 400: invalid request. But, if I take the exact same code from the API, and put it in the client directly (with the secret), it returns the appropriate tokens. The only difference I can think of is the origin. Is there a way around this or is this just not possible?
Thanks in advance.
Nevermind, forgot to stringify the data as part of the request on the server-side. Thanks.
I’ve got a project using a Django backend, with Django Rest Framework to serve an API, and a Vue.js frontend SPA to consume the API. I’m running into some kind of CORS issue during authentication.
I’ve been using mozilla-django-oidc to implement the Authorization Code flow with Okta. This works fine pretty much out of the box, and if I navigate to the API in my browser, I can login to Okta and I get a Django session. I’ve also enabled SessionAuthentication for DRF, which allows the same session cookies generated by Django to be accessible by the SPA (both SPA and API are on the same domain), provided I login first directly through the API. This all works fine until the id token expires. In Django, when the id token expires, I get a redirect to https://example.okta.com/oauth2/v1/authorize?..., the Authorization Code flow completes and I get sent on through to the originally requested page. Where things fail is in an ajax request from the SPA to the API with an expired id token. I get the same redirect, but this time it fails due to CORS.
Access to XMLHttpRequest at 'https://example.okta.com/oauth2/v1/authorize?response_type=code&client_id=X&redirect_uri=http%3A%2F%2F127.0.0.1%3A8000%2Foidc%2Fcallback%2F&state=X&scope=openid+email+profile&prompt=none&nonce=X' (redirected from 'http://127.0.0.1:8080/api/X') from origin 'http://127.0.0.1:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I’ve tried to identify why it’s failing.
On local development, I’m running my API on 127.0.0.1:8000 and my SPA on 127.0.0.1:8080, so clearly the origins don’t match. I have Vue setup with a proxy so it looks like requests are coming from 8080, but the redirect_uri in the request to Okta is still using 8000.
When I deploy to a test server, I’m using docker containers for the API and SPA and a reverse proxy to route requests and also for SSL. In this case, the API and SPA have the same origin (I think). Yet I still get the same error message.
Access to XMLHttpRequest at 'https://example.okta.com/oauth2/v1/authorize?response_type=code&client_id=X&redirect_uri=http%3A%2F%2Fexample.com%2Foidc%2Fcallback%2F&state=X&scope=openid+email+profile&prompt=none&nonce=X' (redirected from 'https://example.com/api/X') from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
If you notice, the redirect_uri is http, not https. I suspect that is why this is failing. Though I’m not entirely confident because if I navigate my browser to the API, I am on https, but the redirect_uri is still http, and it still successfully authenticates.
Any insight would be really helpful.
What am I doing wrong or missing here?
Am I approaching the authentication flow all wrong for an API+SPA app? Should I do authentication on the SPA instead? How does the API then know who’s logged in?
Edit: I have already tried adding the origins to the Security > API > Trusted Origins section in Okta configuration. No dice.
https://developer.okta.com/docs/guides/enable-cors/overview/
In Okta, CORS allows JavaScript hosted on your websites to make a request using XMLHttpRequest to the Okta API with the Okta session cookie. Every website origin must be explicitly permitted as a Trusted Origin.
So configure your Trusted Origins properly in the Okta client configuration.
Are you making an AJAX call to /authorize ? That could be the reason for the error.
As mentioned here, when making requests to the /authorize endpoint, the browser (user agent) should be redirected to the endpoint. You can't use AJAX with this endpoint.
I'm trying to send a POST request to a REST service via AWS API Gateway.
The content-type of the request should be 'application/x-www-form-urlencoded'. It's an authentication service that I'm trying to access. I'm sending 'username' and 'password' in my request body.
When I send the the request via Postman, it works ( It's giving me the proper response ).
But I want to create an API from the API Gateway to access this endpoint.
When I create a POST method in the API Gateway and try to test it without specifying any content-type, the back-end server tells me to send the request by using the content-type 'application/x-www-form-urlencoded'.
Then when I try to put the content-type in 'Mapping Template' section in the 'Integration Request' of the API, the request doesn't even hit the backend. There's an error ( a JSON response ) comes when I test it, saying 'Unsupported Media Type'.
Does anyone out here knows any workaround for this?
I found the solution.
In order to access a POST service using the content-type ‘application/x-www-form-urlencoded’ in API Gateway, make sure you are doing the following in the API console.
Make sure you have enabled the ‘Use HTTP Proxy integration’ as the following in the ‘Integration Request’ section.
When you test the request, make sure you are putting the content type ‘application/x-www-form-urlencoded’ inside the Header’s box as in the following.
And the request body should be like the following as well.
username=user#wellcomww.com.au&password=123456
Since last week I have been struggling to fix this problem but still its not resolved. I have deployed my Django code on AWS lambda and configure the API gateway to serve all api and admin section.
All http method are working fine from rest client/postman but when I am trying to integrating the api in AngularJS then try to perform the POST request to the api but Chrome sends a default OPTION request to the server but every time CloudFront returns an error with 500 status.
"Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource."
Please help me to resolve the issue as I need to move my product to production.
Thanks,
AbdulWahid
Thanks to Michael-sqlbot's comment, I finally succeed to get 200 response from AWS Lambda. Just enable CORS for your Method in API Gateway then it will work.
We are trying to use the API Manager (1.10) to call an existing API (POST) that already uses an Authorization header token. I several things including using mediation according to an article entitled "Pass a Custom Authorization Token to the Backend" and that didn't seem to work.
I finally tried setting the "Auth Type" to "None" which according to documentation should just pass the API call directly to the backend (including the authorization header). This didn't work either. The call gets to the backend service but seems to lose the Authorization header so it throws an 400 error (the same error I get when I leave out the header and call the backend api directly using SoapUI).
Any help would be appreciated!
If you followed the instructions here, it should work.
I have implemented this for several projects and I can attest it did work.
You may turn on wire logs via configuring log4j.properties, inspect the wire log and see what happens.
If you want to have authorization (oauth token validation) at the API gateway as well as want to pass the custom authorization header to back end, you will need to follow the setup described in the documentation[1].
If you want to disable authorization at the API gateway level by setting the authorization type[2] to "none" and want to pass the Authorization header (custom) from client to the back end through the API gateway, you need to do the following steps.
By default, the API gateway will drop the "Authorization" header without sending it to the backend[3]. To send the Authorization header to the backend through the API gateway, uncomment the following property and set its value as "false" in <wso2am-home>/repository/conf/api-manager.xml and
<RemoveOAuthHeadersFromOutMessage>false</RemoveOAuthHeadersFromOutMessage>
[1] https://docs.wso2.com/display/AM1100/Pass+a+Custom+Authorization+Token+to+the+Backend
[2] https://docs.wso2.com/display/AM1100/Key+Concepts#KeyConcepts-HTTPmethods
[3] https://docs.wso2.com/display/AM1100/FAQ#FAQ-HowcanIremovetheauthenticationheadersfromthemessagegoingoutoftheAPIGatewaytothebackend