Don't Panic
in Springboot ☕ 5분 읽기

[Springboot] Spring Security, OAuth2, JWT — 인증 시스템 완전 정복

#Springboot
목차

Spring Security — 자체 로그인 구현

Spring Security 모듈을 사용하면 자체 로그인을 비교적 쉽게 구현할 수 있다. 핵심은 사용자 정보를 조작 없이 안전하게 주고받는 것이며, 시큐리티는 세션 기반으로 로그인 상태를 관리한다.

  • @EnableWebSecurity: Spring Security 모듈이 보안 설정을 자동으로 진행하도록 활성화
  • HttpSecurity: 보안 설정의 핵심 객체. 빌더 패턴으로 구성하며 antMatchers로 요청 허가 범위를 지정
  • 로그인 후 세션 초기화 시 .and() 체이닝으로 세션에 저장된 로그인 정보를 해제할 수 있음

Spring Security 설정 예시

HttpSecurity 빌더 구성

로그인 처리 흐름

  1. 사용자가 폼에 입력한 정보를 POST로 전송
  2. memberService.signUp()이 새 엔티티를 생성해 Repository에 저장
  3. 로그인 요청 시 비밀번호를 PasswordEncoder 인터페이스로 인코딩해 DB와 매칭 검증
  4. UserDetailsService 구현체를 통해 유저를 식별하고, Bean으로 등록하면 Spring Security가 자동으로 가져다 사용

회원가입 페이지 예시

Spring Security에서 자체 로그인을 구현하는 핵심은 UserDetailsService 구현과 PasswordEncoder 빈 등록이다. Spring Boot는 미리 정의된 인터페이스를 통해 개발자가 필요한 부분만 구현하도록 유도한다.

CSRF (Cross-Site Request Forgery) 토큰

  • CSRF: 서로 다른 출처의 사이트에서 동일한 요청을 보낼 수 있는 보안 취약점
  • CSRF 토큰: 서버가 발급한 토큰을 요청에 포함시켜 정상적인 사이트에서 온 요청임을 검증
  • HTTP는 무상태(Stateless)이므로, 요청의 출처를 식별하기 위한 별도 메커니즘이 필요

소셜 로그인 — OAuth2 (Open Authorization 2.0)

OAuth2: 접속자 정보를 비밀번호 없이 안전하게 주고받기 위한 개방형 표준. 대부분의 소셜 로그인은 OAuth2 기반으로 구현된다.

OAuth2 전체 흐름 다이어그램

네이버 소셜 로그인 적용 절차

  1. 네이버 개발자 센터에 애플리케이션 등록 (이용신청)
  2. 콜백 URL(Redirect URI) 설정 — 인증 후 어디로 돌아올지 지정
  3. 제공되는 SDK를 HTML에 삽입해 로그인 버튼 구성

네이버 앱 등록

콜백 URL 설정

SDK 설정

소셜 로그인 인증 흐름

  1. 프론트 SDK가 네이버 인증 서버로 요청
  2. 사용자 동의 후 인증 서버가 Access Code를 콜백 URL로 반환
  3. 프론트가 Access Code를 백엔드로 전달
  4. 백엔드가 네이버 인증 서버에 Access Code를 보내 Access Token 획득
  5. Access Token으로 Resource Server에서 사용자 정보(Protected Resource) 수신
  6. refresh token으로 Access Token 갱신 가능

네이버 로그인 버튼 스크립트

네이버 로그인 인증 화면

Access Token 흐름

네이버 제공 사용자 정보 항목

  • 부족한 정보가 있으면 ExceptionHandler를 설정해 추가 입력을 요청할 수 있음
  • 구글/페이스북/애플은 OAuth2 설정이 더 복잡하며, 공식 매뉴얼 참고가 최선

구글 등 타 플랫폼 OAuth2

JWT (JSON Web Token)

  • JWT: 로그인 세션 없이 HTTP 상에서 인증 정보를 주고받을 때 사용
  • 누구나 해독(decode)할 수 있지만, 아무나 만들 수는 없음
  • 생성에는 공개키(public key) + 비공개키(private key) 모두 필요
  • 검증에는 공개키만 필요

참고: http://jwt.io

JWT 구조 및 검증

SSO (Single Sign-On)

JWT는 SSO 구현에 많이 사용된다. 동일 출처의 여러 사이트(예: 네이버, 네이버 스포츠, 네이버 연예) 사이에서 매번 인증 없이 로그인 상태를 유지하는 방식.

  • OAuth2 로그인(다른 서비스에서 사용자 정보 확인)과는 다른 개념
  • 보통 쿠키에 저장해 사용하며, 민감 데이터는 백엔드에서 프론트로 전달하는 것이 안전

JPA ddl-auto 설정 주의사항

옵션동작사용 환경
create시작 시 테이블 새로 생성 (기존 데이터 삭제)개발/테스트 전용
create-drop시작 시 생성, 종료 시 삭제개발/테스트 전용
update변경 사항만 반영개발 환경
none자동 DDL 없음운영 환경 권장

운영 환경에서 create를 실행하면 기존 데이터가 모두 삭제된다. 운영에서는 none을 사용하고, 스키마 변경은 DBA가 직접 처리해야 한다. DB 스키마 변경 후 서버를 update로 기동하는 순서를 지킬 것.

ddl-auto 설정 예시

DB 테이블 설계 — 조인 테이블

게시글 서비스를 예로 들면, 엔티티 간 관계를 다음과 같이 설계할 수 있다.

  • article ↔ file: 파일이 1개만 허용이면 article 테이블에 직접 포함. 다수 파일이면 별도 조인 테이블 필요
  • article ↔ comment: ref: > article.id로 외래키 연결
  • following: following, follower 두 컬럼만으로 구성 가능
  • subscribe: following과 동일한 구조로 확장 가능

조인 테이블 없는 구조

조인 테이블 적용 구조

following 테이블 구조

subscribe 테이블 구조

조인 테이블은 다대다(N:M) 관계에서 필요하다. 하나가 여러 개를 가지는 1:N이라면 조인 테이블 없이 FK로 처리할 수 있다.

개발 마인드셋 & 도구 팁

  • 초기에 너무 망설이지 말고 일단 만들어본 뒤 문제를 찾아 개선하는 것이 올바른 방향
  • 구글/아마존도 하루에 수천 번 배포하며 완벽을 추구하지 않음
  • 기존 서비스를 보며 “이건 어떻게 구현했을까” 상상해보는 것이 좋은 연습

유용한 설계 도구:

백엔드 개발자 로드맵 (권장 순서):

  • Docker: 사용법 수준은 필수 소양
  • Kubernetes: 작동 원리와 흐름 파악 권장 (대체재: Docker Swarm, ECS 등)
  • 클라우드(AWS 등): 백엔드 영역 확장의 좋은 출발점

관련 글