이 게시글은 강의를 듣고 정리한 내용이 주를 이루고 있습니다.
수강 강의 : (인프런) 스프링부트 시큐리티 & JWT 강의
🏠 https://github.com/devwuu/spring-security-exam
0. Spring boot 3.x + Spring security 6.x 사용으로 인한 변경사항
강의는 구버전 기준이라 현재 버전으론 deprecated된 부분들이 있어 사용 방법이 좀 바뀌었다
공부하면서 적용한 상세 코드는 github에 정리 되어 있고 공부하면서 참고한 사이트는 하기와 같다
-
Spring security filter 적용 방법
➡️ websecurityconfigureradapter 가 deprecated 되었다!!!
https://docs.spring.io/spring-security/reference/migration-7/configuration.html
https://docs.spring.io/spring-security/reference/reactive/integrations/cors.html -
AuthenticationManager 등록 방법
https://stackoverflow.com/questions/74877743/spring-security-6-0-dao-authentication
➡️ authenticationmanager without websecurityconfigureradapter 으로 검색해보면 좀 더 다양한 방법이 나오는 거 같다
1. Spring security session 구조
- session 영역 안에 Security가 관리하는 session 영역이 있다.
- security session 영역 안에는 Authentication 타입만이 포함될 수 있다
- Authentication 안에는 UserDetails 타입과 Oauth2User 타입이 포함될 수 있다.
때문에 UserDetails과 Oauth2User의 공통된 타입을 만들어주는 것이 좋다.
그렇게 되면 하나의 타입을 가지고 유연하게 활용할 수 있기 때문이다.
2. Session
2-1. Session 을 이용한 인증 방식
- 웹사이트 최초 접속 (www.test.com)
- reqeust의 쿠키가 비어있기 때문에 서버에서는 세션 id와 저장소를 생성한다.
- 생성한 session id를 response 해준다
- client에서 응답받은 session id를 쿠키에 저장한다
- client에서 웹사이트 로그인을 요청한다.
request header(쿠키)에 session id를 넣어서 요청을 보낸다. - server에서는 정상적인 사용자인지 확인한다
DB와 통신해서 User 정보를 조회해온다
정상적인 사용자일 경우, session id를 확인해서 해당 저장소에 user 정보를 저장한다 - server가 응답하고 로그인 처리가 완료된다
- client에서 회원 정보를 요청한다
request header의 쿠키에 session id를 넣어서 요청을 보낸다. - server에서는 해당 session id를 가지고 저장소에서 로그인 한 유저인지 확인한다.
필요하다면 DB와 통신해서 필요한 User 정보를 조회해온다 - server가 user 정보를 응답한다
2-2. Session 을 이용한 방식의 문제점
- 동시 접속자가 많아지게 되면 세션이 그만큼 많아지게 돼서 서버의 부담이 늘어나게 된다.
- 서버가 다중화되면 통신하는 서버가 바뀔 때마다 인증이 필요하다
(1) A 서버와 통신하여 로그인에 성공, A 서버의 세션에 유저 정보가 저장됨
(2) B 서버와 통신하여 유저 정보 요청, B 서버의 세션에는 로그인된 유저 정보가 없기 때문에 새로이 인증해야 함
2-3. 해결방법
- Sticky Session
- Session 복제
- DB에 세션값 저장
- 메모리 서버(e.g. Redis) 사용
- JWT 사용
3. 쿠키
3-1. 쿠키와 인증
- server에서는 session id를 response 한다.
- client에서는 쿠키에 해당 session id를 저장한다.
- 이후 발생하는 request의 쿠키에 session id를 담아 요청한다.
- 쿠키는 특별한 조치 없이도 자동으로 header에 담겨서 요청되기 때문에 편리하다
3-2. 쿠키의 문제점
- 같은 도메인이 아니면 쿠키가 날아가지 않는다.
쿠키는 기본적으로 동일 출처 정책을 사용한다. - 그렇다고 해서 javascript 등을 이용해서 의도적으로 쿠키를 셋팅해 request 하게 되면
서버에서는 보통 쿠키에 대한 설정을 http only로 해두기 때문에 이런 요청은 받지 않는다. - 그렇다고 해서 http only 설정을 꺼두게(false)되면 보안 취약점이 된다.
3-3. 해결방법
- header에 쿠키가 아니라 Authorization으로 인증 정보를 담아 요청한다
- 이 Authorization 에 id와 password를 담는 게 HTTP Basic 방식이다.
하지만 id와 password를 담게 되면 정보가 노출됐을 때 상당히 위협적이기 때문에 만약 사용한다면 HTTPS로 사용합니다 - JWT는 Authorization에 토큰을 넣는다. 이러한 방식을 Bearer 방식이라고 한다.
일단 id와 password가 아니라는 점에서 Basic 방식보다 위험 부담이 적다.
일단 한다