본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 26일차!
오늘은 커뮤니티 피드 서비스에 추가할 기능들의 개요와 jwt / 인증 인가 / OAuth 개념 학습을 진행하였다.
Part2에서는 실무에서 대부분 쓰이는 인증과 Admin 기능을 구현하기로 했다.
JWT (Json Web Token)
: 서버와 클라이언트 사이 통신에서 사용되는 JSON 형태의 웹 토큰
- 서버의 확장성이 높고, 특정 DB나 서버에 의존하지 않아도 됨
- 헤더, 페이로드, 시그니처로 구성 (헤더.페이로드.서명 <- 점 (.) 으로 구분)
헤더: 토큰 유형, 사용 중인 서명 알고리즘
페이로드: 사용자에 대한 데이터 (아이디, 만료시간, 역할 등)
서명: 토큰의 무결성과 인증을 보장하는 암호화된 서명 (인코딩된 헤더, 페이로드, 비밀키를 결합하여 생성)
JWT를 사용한 인증 방식의 전체적인 흐름이다.
1. 사용자가 로그인하면 서버에서는 JWT 값을 반환
2. 클라이언트는 받은 JWT를 로컬 스토리지나 쿠키에 저장
3. 이후 서버로 요청할 때, 클라이언트에서 Authorization header에 JWT를 담아서 보냄
4. 토큰을 받은 서버는 서명을 확인하고 내용을 파싱하여 데이터를 사용
Access Token 만료 시, 클라이언트는 refresh token을 이용해서 새로운 토큰 발급
토큰을 이용한 인증 방식은 세션/쿠키 방식과 많은 차이점이 있다.
1. 상태관리
- 세션/쿠키: 상태 유지 (서버가 세션 데이터를 관리)
- jwt: 무상태 (서버 측 세션 데이터 없음)
2. 확장성
- 세션/쿠키: 분산 환경에서 확장성이 낮음
- jwt: 확장성이 매우 높음
3. 폐기 용이성
- 세션/쿠키: 용이 (서버에서 세션 무효화가 가능함)
- jwt: 어려움 (토큰 블랙리스트가 필요함)
4. 보안
- 세션/쿠키: 안전하지만 특정 공격에 취약 (세션 탈취, CSRF)
- jwt: 적절한 구현 시 안전 (HTTPS)
5. 저장 위치
- 세션/쿠키: 서버 측에서 세션 데이터를 저장
- jwt: 클라이언트 측에서 토큰을 저장
6. 크로스 도메인 지원
- 세션/쿠키: 동일 출처 또는 CORS 설정에 제한됨
- jwt: 크로스 도메인 지원
인증/인가
- 인증: 사용자를 식별하는 프로세스 (로그인)
- 인가: 권한을 확인하는 프로세스 (유저가 해당 api를 사용할 수 있는지)
ㄴ jwt에 user의 권한을 role base로 추가해 admin과 일반 유저를 구분하는 방식으로 구현
OAuth
: third-party 어플리케이션에서 유저의 정보에 접근할 수 있게 하는 표준 프로토콜 (소셜 로그인이 대표적)
ㄴ 단, 비밀번호와 같은 데이터는 공유하지 않고 제한된 정보를 제공
1. resource owner: 데이터를 가지고 있는 유저
2. client: 데이터 접근을 하려고 하는 서드파티 어플리케이션
3. authorization & resource server: 토큰을 발급하고 데이터를 제공하는 서버
세션 기반의 로그인 기능만 구현해본 경험이 있기에 꼭 한번 JWT를 사용해보고 싶었는데, 이번 강의에서 배울 수 있게 되어 기쁘다!