[TIL] OAuth2와 JWT를 같이 사용한 이유

chanbyeong·2025년 3월 18일

프로젝트에서 OAuth2를 이용하여 소셜 로그인을 구현했다. OAuth2 라이브러리만 사용하여 구현할 수도 있었지만, OAuth2 인증 후에 서비스 자체 JWT를 발급하여 구현했는데, 왜 이런 방식을 사용했는지 작성 했다.

OAuth2만 사용하여 구현할 경우에는 어떤 문제점이 있을까?

매 요청마다 OAuth2 Provider에 Access Token을 매번 검증을 요청해야 해서 성능 저하 발생
- Provider의 인증 서버와 매번 통신해야 하므로 네트워크 지연
- 대량의 요청이 발생한 경우, OAuth2 Provider의 API 제한에 걸릴 가능성이 있음
OAuth2 Provider마다 Access Token의 발급 방식과 검증 방식이 다를 수 있음
- Google, Kakao, Naver 등 Provider 별로 Access Token을 발급하는 방식과 만료 정책이 다름
- Provider이 다르면 각 Provider 별로 다른 방식으로 Access Token을 관리해야 하므로 복잡성 증가
OAuth2 Provier의 Access Token 만료 시간 문제
- Access Token은 기본적으로 만료 시간이 짧음
- 만료되면 OAuth Provider의 Refresh Token을 사용하여 새로운 Access Token을 발급 받아야 함
- 하지만 OAuth2 Provider 정책에 따라 Refresh Token이 만료될 수 있음
OAuth2 Access Token은 우리 서비스의 API 인증에 최적화 되지 않음
- OAuth2 Access Token은 OAuth2 Provider의 API를 호출할 때만 유효
- 하지만 우리 서비스 내에서도 사용자 인증이 필요하므로, 별도의 인증 방식이 필요함

OAuth2 Access Token은 Proivder가 관리하지만, 서비스 자체 JWT는 우리 시스템에서 제어 가능
- OAuth2 Provider에 대한 종속성이 줄어듬
- OAUth2 Provider의 정책 변경이 있어도, 우리 서비스에는 영향이 적음
JWT는 자체적으로 정보를 포함하므로, 추가적인 인증 서버 요청 없이 검증 가능 -> 성능 향상
- JWT는 서버에서 자체적으로 검증 가능하므로, OAuth2 Provider의 매번 검증 요청을 보낼 필요 없음
- OAuth2 Provider와 불필요한 통신을 줄여 성능 최적화 가능

JWT를 추가적으로 선택한 가장 큰 이유는 OAuth2 Provider에 대한 종속성이 줄이기 위함이었다.
또한, 카카오와 구글 두 가지 OAuth2 Provider를 사용했는데, 각 Provider의 Access Token을 따로 관리해야 한다는 점이 복잡성을 증가시켰다.
결과적으로 서비스 자체 JWT를 발급함으로써
- 서비스 내부에서 인증을 독립적으로 관리 할 수 있게 되었다.
- OAuth2 Provider의 불필요한 API 호출을 줄여 성능을 최적화 했다.
- OAuth2 Access Token 만료 여부와 관계 없이 안정적인 시스템 구축 할 수 있었다.