JWT의 인증 서버
이전 포스트까지는 JWT에 대해 구체적으로 알아보았다.
이번에는 “인증 서버”에 관련해서 작성한다.
직전에 이 “인증 서버”가 무엇을 의미하는 지 아직 모르겠다고 했는데…
이 인증 서버라는 것 자체가 그냥 멤버쉽 인증, 인가 관련된 로직을 의미한다.
쉽게 말하면 “샐로그” 프로젝트에서 나는 auth 패키지에 인증, 인가, 로그인, 토큰 재발급 등 회원 보안 관련 로직을 모두 담았다.
이 의미는 이 auth 패키지 자체가 “내부 인증 서버”라는 뜻이다.
만약 Oauth2 를 구현하게 되면 외부 인증 서버를 활용해 인증, 인가 처리를 하게 되는 것이다.
그러니까 구글, 네이버 등에 인증 서버를 맡기는 것이다.
혹은 클라우드 기반 서비스도 있기는 하지만 헷갈리기 때문에 두 가지의 경우만 생각한다.
지금까지 구현했던 로그인, 인가, 권한 설정 등 그 자체가 “인증 서버”였고, 나는 내부 인증 서버를 구축한 것이다.
인증 서버라는 것이 처음에는 빌드 옵션이거나 무언가 특정 서버를 거쳐 인증 처리되는 흐름을 생각했는데, 진짜 간단히 생각하면 내가 “서버” 개발자이고 관련된 로직을 작성하면 외부에서는 해당 로직을 가진 “서버”가 “인증 서버”가 되는 것이었다.
이것을 몰라 누군가가 “인증 서버는 어떻게 하셨나요?”라고 하면 “잘 모르겠습니다.” 내지 “기본적으로 있는 걸로 했습니다.” 이런 답변이 나왔었다.
웃긴 일이지만 지금까지 내가 구현한 인증, 인가 관련 로직이 “인증 서버”였는데, 말의 의미를 몰라서 엉뚱한 대답을 했다.
지금 생각해보니 아주 부끄럽다…
어찌됐든 이제는 이 말의 의미를 알게 되었으니 단순히 말로만 끝내기는 뭔가 아쉽다.
하지만 이 포스트는 이렇게 깨달은 것을 작성하고 마무리할 것이다.
하나의 포스트에는 하나의 책임만… 객체지향적인 블로깅을 통해 짧더라도 복잡하지 않게 가져가기로 했기 때문이다.
위에서 말했듯이 하나의 포스트에는 하나의 책임만 갖도록 앞으로는 너무 길게 작성하지는 않을 것이다.
이전 블로그, 그리고 이번 블로그에서도 길게 쓰는 일이 많았었는데 그렇게 하니까 내가 다시 보기도 힘들더라.