헤더에도 신경을 쓴다면?

오랫동안 백엔드와 프론트엔드 서버를 분리해 엑세스 토큰으로 인증과 인가를 확인해왔던 모델을 보면 많은 경우에 있어 인바운드에선 토큰이 헤더로 들어오지만 아웃바운드에선 메시지의 바디로 넘겨주는 모순을 볼 수 있었다

그래서 10년전부터는 서버에서 인증시 발급하는 엑세스 토큰을 헤더로 넘겨주면서.. 넘겨준 그대로 헤더의 키로 다시 매칭시켜 전달받을 수 있는 일관된 모습을 만들어왔다며

후후.. 이렇게 바디안엔 인증된 사용자의 데이터만 실으며, 토큰은 헤더에 분리해서 넣는 관심사의 분리가 이루어졌다

그러나..

분산시스템이라는 개념이 없던 웹서비스 초기에 만들어진 레거시한 보안규약으로 인하여 CORS 문제가 따라붙게 된다며

왜? 분리 아키텍쳐에선 이미 CORS 문제는 초기에 해결하고 진행한 형태일텐데? 맞는말이지만 Customizing Header를 통과시키기 위해선 한가지 더 신경써야할 부분이 있다며

일반적으로 위와 같이 팩토리를 구성하여 컨테이너에 주입하면 Authorization 이라는 헤더는 CORS가 되지 않아, 프론트엔드에 도달하지 못하고 패킷을 강탈당한다

allowedHeaders 가 http 의 기본 헤더들을 통과시킨다면, exposedHeaders 는 커스티마이징된 헤더들을 통과시킬 수 있는 값이라며

그치만 많은 경우에 있어 WebMvc에 Security를 붙이면 요청 트랜잭션이 Security의 필터들까지 확장되기에 다음과 같이 처리한담서

시큐리티에서 CORS로 인정할 디폴트 리소스를 처리하는 applyPermitDefaultValues() 는 미리 약속된 origins, methods, headers 들을 등록하며,

연이은 addExposeHeader에 와일드카드 패턴으로 앞으로 백엔드에서 만들 모든 커스팅 헤더들도 CORS로 통과할 리소스로 인정하게 만든다는 의미라며

이로서 액세스토큰은 요청시에도 헤더로 들어오며, 응답시에도 헤더로 나갈 수 있게 되었담