# 문제점
회원가입 API를 구현한 뒤 가입된 사용자에 대해서 로그인 요청을 받고 가입이 된 사용자에 한해 사용자에 대한 정보를 저장하고 관리할 방법이 필요하다고 판단했습니다.
이를 구현할 수 있는 방법은 크게 세션/쿠키 방식 과 JWT 방식을 생각해봤고 각 방식에 대한 기본 설명은 아래와 같습니다.
# 해결방안
1) 세션 / 쿠키 방식
세션은 서버측에서 사용자에 대한 고유 세션 ID를 발급하고 저장하여 관리하는 공간을 의미합니다.
쿠키는 클라이언트 측에서 발급받는 세션 ID를 저장하여 이후 요청을 보낼 때 헤더에 함께 담아 보내기 위한 저장 공간을 의미합니다.
동작 순서
- 로그인 요청을 보낸 사용자에 대한 고유 세션 ID를 생성
- 서버는 세션 ID와 사용자의 일부 정보를 세션에 저장(Map 형식)
- 세션 ID를 응답 객체 해더에 담아 클라이언트에 전송
- 이후 요청을 보낼 때 쿠키에 ID를 담아 전송
- 서버는 이를 활용해 로그인된 사용자의 요청인지를 검증을 진행
장점
- 클라이언트에 노출되는 세션 ID 자체는 무의미한 값을 가진다.
- 고유한 ID값을 가진다.
단점
- 서버에 추가적인 저장공간을 필요로 한다.
2) JWT 방식
JWT(Json Web Token) 방식은 암호화된 토큰을 발행해 클라이언트에 보내고 이를 복호화함으로써 검증하는 절차를 의미합니다.
동작 순서
- 로그인 요청을 보낸 사용자에 대해 임의로 생성된 토큰을 생성
- 토큰을 헤더에 담아 클라이언트로 전송
- 이후 다른 요청을 보낼 경우, 헤더에 해당 토큰을 담아서 요청
- 서버측에선 해당 토큰에 대한 검증 진행
장점
- 별도의 저장공간을 필요로 하지 않는다.
단점
- 이미 빌급된 JWT 토큰의 경우, 유효기간이 만료될 때까지 사용이 가능하다.
즉, 해당 토큰이 노출되면, 다른 누군가가 이를 탈취해 악의적으로 사용할 수 있다.
# 채택한 방식은?
결론부터 말하자면 두 방식 모두 사용할 수 있는 설계를 작업하기로 했습니다.
다만 1순위로 사용할 방식을 세션/쿠키 방식으로 결정했습니다.
이유는 토큰 방식에 비해 안정성 자체는 뛰어나단 점과 이후 Redis를 활용할 방안을 고려중에 있기에 세션 방식을 우선적으로 사용하는 것이 합리작이라 판단했습니다.
인증 방식에 대한 교체는 충분히 발생할 수 있는 이슈라 생각했고, 객체 지향스로운 설계를 구성하기 위해 두 방식을 유연하게 교체할 수 있는 구조로 작업해보기로 했기에 두 방식에 대한 차이점을 알고 있고 상황에 맞는 방식을 활용하는 것이 합리적이라 판단했습니다.
# 마치며
로그인 인증 방식을 위해 선택해 볼 수 있는 두 방식에 대해 학습하고 장,단점을 비교해 프로젝트에 합리적인 선택을 해보기 위한 고민을 해볼 수 있었습니다.
# 참고자료
- https://tofusand-dev.tistory.com/89
- https://ecsimsw.tistory.com/entry/Load-Balancing%EA%B3%BC-%EC%84%B8%EC%85%98-%EC%9C%A0%EC%A7%80-Sticky-Session-Session-Clustering
- https://velog.io/@gmtmoney2357/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B6%80%ED%8A%B8-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98#-%EC%BF%A0%ED%82%A4%EB%A7%8C%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8