이젠 MSA 라고 한다면 정답이 없다고 무방할 정도로 많은 선택지가 존재하고, 그 선택지 중에서 가장 자신의 프로젝트에 맞는 선택을 하면 된다고 생각한다.
그 중에서 인증/인가 처리에 대한 얘기를 해보자 한다.

현 진행 프로젝트의 초기 아키텍처 구상 구조이다.
인증/인가 측면에서만 본다면 Gateway Server에서 진행하려고 생각했다.
이유로 들자면 다음과 같다.
이렇게 생각했기에 나는 Auth Server 즉, 인증 서버의 존재에 대한 의문이 들기 시작했다.
많은 질문에 대한 답으로 내 생각을 정리해 남기려 한다.
인증 서버가 왜 필요할까?
여기엔 많은 이유가 존재할 수 있다.
User 서버의 트래픽 증가라던지 관심사를 분리할 수도 있고, User 권한에 따른 다양한 서버가 파생되면서 다양한 인증/인가 처리가 필요할 때 인증서버를 통해 처리할 수 있다.
또한 Gateway가 늘어나거나 User 서버가 늘어남에 따라 인증 서버 또한 자유롭게 Scale-out이 가능하다.
이 답변으로 인증 서버의 존재에 대한 의문이 해결되었다.
또 다른 질문으로는
인증 서버에서 어떤 처리가 가능할까?
간단하게 생각해 봤을 때는 현재로썬 회원가입/로그인 그리고 다양한 인증/인가에 필요한 api 정의 정도가 될 것 같다.
만약 User 의 권한에 따른 다양한 서버가 파생되었을 때, 좀 더 많은 처리가 가능할 것 같다.
만약 추가해야 한다면 언제 추가하는게 좋은걸까?
이 부분도 정답은 없다.
나눠서 개발할 생각이라면 처음부터 나눠도 될 것 같고, 특정 상황이 닥쳤을 때 분리하는 방법도 괜찮은 것 같다.
그래서 어떤 방법으로 개발할건데?
라고 물으면 이번 프로젝트에서는 처음부터 Auth Server를 구현할 것이다.
목적은 공부 목적으로 Auth Server를 구성했을 때, Gateway와 user 서버간의 통신도 생각해줘야 할 것 같고, 어떤 역할이 들어가야 하는지 등등 생각해줄 부분이 많을 것 같기 때문이다.

이런식으로의 아키텍처를 구상해볼 수 있을 것 같다.
Auth 서버에선 spring security를 통해 토큰 파싱 및 인증/인가 처리를 해줘야 할 것 같고, user 서버로 질의가 필요한 권한들은 들린 후, 최종 반환값을 Gateway로 전달하면 될 것 같다.
gateway에서는 auth서버로 토큰 파싱 요청을 하고, 받아온 반환값으로 각 서버의 요청 헤더로 전달하면 될 듯 하다.
회원가입/로그인은 auth url prefix를 가지고 있기에 별도의 토큰 확인 없이 auth 서버로 전달하면 될 것 같다.
우선 내 생각은 이정도로 추가로 고민이 필요한 사항이 생기면 글을 계속 추가해보려한다.