[Spring] JWT - 인증과 인가, 그리고 Access, Refresh Token

#인증인가 #Acess, Refesh Token

💡 Spring 정리: 인증과 인가, 그리고 Access,Refresh Token

📘 개념 정리

1. 인증과 인가         

항목	인증 (Authentication)	인가 (Authorization)
의미	"누구인지 확인"	"무엇을 할 수 있는지 확인"
초점	사용자 본인 여부	권한/역할 확인
예시	ID/PW 입력 → 사용자 인증	관리자만 게시물 삭제 가능
언제?	로그인 시점	리소스 요청 시점
결과	Access Token 발급 등	요청 허용/거부 판단

  2. Access Token vs Refresh Token

항목	Access Token	Refresh Token
역할	인증된 사용자인지 확인	Access Token 재발급용
유효기간	짧음 (수분~수십분)	김 (보통 며칠~일주일 이상)
저장 위치	쿠키, localStorage 등	HttpOnly 쿠키 권장
노출 시 위험도	높음 (API 접근 가능)	높음 (Access 재발급 가능)
서버 저장 여부	❌ (무상태 인증)	✅ 보안 위해 DB/Redis에 저장 가능
전송 위치	HTTP Header (Authorization)	자동 전송 or 별도 요청

🔄 동작 흐름

1. 로그인 성공 시 → 두 토큰을 모두 발급
2. 요청 시 → Access Token으로 인증
3. 만료되면 → Refresh Token으로 재발급
4. 둘 다 만료 → 재로그인 필요

 

⚠️ 실수 및 주의사항

• 보안을 위해 Access는 짧게, Refresh는 신중하게 보관하는 전략을 사용해야 함

✨ 궁금증

Refresh Token은 발급 후 어디에 저장할까?

• Access Token 만료 시 재발급에 사용
• 탈취되면 Access Token도 재발급 가능하기 때문에 보안이 매우 중요함

저장 위치	설명	장점	단점
HttpOnly 쿠키	브라우저에 저장하되 JS 접근은 불가능	XSS 방어	CSRF에 취약할 수 있음
서버 DB (또는 Redis)	Refresh Token을 사용자 식별자와 함께 저장	탈취 시 서버에서 무효화 가능	서버 부하 증가
모바일/SPA: SecureStorage or Memory	앱의 보안 영역 또는 메모리 저장	오프라인 캐시 가능	XSS/XSRF 고려 필요

 

💡 Refresh Token을 서버에 저장하는 이유

• 중복 로그인 방지: 로그인 시 이전 Refresh 무효화
• 강제 로그아웃 처리 가능
• 토큰 탈취 시 서버에서 선제적 차단 가능
• 1회성 토큰(rotate) 전략 사용 가능

      로그인 → 서버에 refresh 저장 → 재발급 시 기존 토큰 삭제 → 새로 저장

✅ 결론

환경추천 저장 위치

웹 (보안 최우선)	HttpOnly 쿠키
SPA (보안/확장성 고려)	Access는 메모리 / Refresh는 HttpOnly 쿠키 or Redis
모바일	SecureStorage or DB 저장소
민감 시스템(은행 등)	Refresh를 DB/Redis에 저장하여 서버에서 철저히 관리

 

 

🔗 참고 자료

https://note8770.tistory.com/153

[Spring] JWT