이렇게 다 설정을 하고 Postman 에서 테스트를 해보았을때는 잘 되는데
배포 환경에서 테스트를 할 때 CORS 에러가 발생한다
API Gateway에서 CORS 활성화를 해주었다.
이번엔 preflight 요청에선 200이 뜨는데 본 요청에선 CORS 오류가 뜬다.
CORS 활성화 설정을 해서 OPTIONS 요청에 강제로 200을 리턴하도록 설정해서 그런것 같다.
람다 함수에서 CORS 관련 헤더를 설정해주었다.
const allowResponse = generateAllow(awsRequestId, methodArn, userId);
// CORS 관련 헤더 설정
allowResponse.headers = {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Headers': 'Content-Type,Authorization',
'Access-Control-Allow-Methods': 'GET,POST,PUT,DELETE',
'Access-Control-Allow-Credentials': true,
};
return allowResponse;
하지만 Lambda Authorizer 에서 반환하는 응답에는 policyDocument
, principalId
로 구성되어야 하기 때문에 오류가 발생한다..
권한 부여자를 제거하고 요청을 보냈을때 OPTIONS에서 응답으로
Access-Control-Allow-Headers 에 authoriztion과 member-id가 오는것을 확인했다.
프론트에서 테스트 과정중에 member-id를 헤더에 담았기 때문에 발생한 문제였다.
따라서 요청에서 해당 헤더를 제거하거나 API GATEWAY의 OPTIONS 메소드 통합 요청에 해당 헤더를 추가해주면 해결된다.
우선 해결은 했지만 Authorizer를 연결하면 왜 CORS가 뜨는건지에 대한 의문점이 들었다.
Authorizer 연결전 Preflight 요청
CORS 관련 헤더들이 포함되어 응답이 오는것을 볼 수 있고 정상적으로 200 응답을 받는다.
Authorizer 연결후 Preflight 요청
401 Unauthorized가 발생한다.
OPTIONS 요청에는 요청에 Authorization 헤더를 포함하지 않으므로 권한없음 의 응답을 받는다.
그렇기 때문에 본 요청에서는 CORS 에러가 터지게 되는것이다.
따라서 API Gateway에서 CORS 활성화 설정을 통해 OPTIONS 요청에 대해 200 응답을 하도록 하여 CORS 에러를 해결해야 한다.
이렇게 하여 API Gateway와 Lambda를 이용한 권한부여자로 JWT 를 검증하고, ID 를 추출하여 헤더에 실어 보내는거 까지 완료하였다.
백엔드 서버에서는 이제 토큰을 검증할 필요가 없고 헤더의 ID 를 추출하여 요청을 보낸 유저가 누구인지 확인 할 수 있다.
API Gateway에서의 통합된 인증을 통하여 확장성 있고 유연한 관리를 할 수 있게 되었다.