HttpServletRequest, HttpServletResponse
WAS가 웹브라우져로부터 Servlet요청을 받으면
1. 요청을 받을 때 전달 받은 정보를 HttpServletRequest객체를 생성하여 저장
2. 웹브라우져에게 응답을 돌려줄 HttpServletResponse객체를 생성(빈 객체)
3. 생성된 HttpServletRequest(정보가 저장된)와 HttpServletResponse(비어 있는)를 Servlet에게 전달
HttpServletRequest
4. Http프로토콜의 request 정보를 서블릿에게 전달하기 위한 목적으로 사용
5. Header정보, Parameter, Cookie, URI, URL 등의 정보를 읽어들이는 메소드를 가진 클래스
6. Body의 Stream을 읽어들이는 메소드를 가지고 있음
HttpServletResponse
Servlet은 HttpServletResponse객체에 Content Type, 응답코드, 응답 메시지등을 담아서 전송함
[출처] https://zester7.tistory.com/33
JWT란 무엇일까?
JWT(Json Web Token)란 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token
일반적으로 쿠키 저장소를 사용하여 JWT를 저장.
- 서버가 1대인 경우 --> Session1 이 모든 Client의 로그인 정보를 소유
- 서버가 2대 이상인 경우 --> Session 마다 다른 Client 로그인 정보를 가지고 있을 수 있다.
모든 서버가 클라이언트를 동일하게 인식하기 위한 방법
1. Sticky Session: Client 마다 요청 Server 고정
(로드밸런서는 랜덤하게 서버를 연결시키기 때문에 이걸 고정시켜버리는 것)
2. 세션 저장소 생성하여 모든 세션을 저장
3. JWT 사용
모든 서버에서 동일한 Secret Key소유해야함. (외부에 저장하는게 아니라 동일한 값을 갖는 것임)
Secret Key는 암호화 / 위조 검증 모두 수행. (복호화 시)
JWT 장/단점
1. 장점
- 동시 접속자가 많을 때 서버 측 부하 낮춤 (외부의 다른 서버에 연결해서 체크하는게 아니라 연결된 서버 자체로 검증 가능하기 때문)
- Client, Sever 가 다른 도메인을 사용할 때
2. 단점
- 구현의 복잡도 증가 (세션 서버 따로 만드는 것에 비해)
- JWT 에 담는 내용이 커질 수록 네트워크 비용 증가 (클라이언트 → 서버)
- 기 생성된 JWT 를 일부만 만료시킬 방법이 없음 (서버가 클라이언트의 쿠키에 있는 JWT를 만료 시킬 방법이 없음 -처음에 쿠키나 JWT의 만료 기한 설정은 가능)
- Secret key 유출 시 JWT 조작 가능 (JWT는 open 되어 있어서 누구나 열람 가능. -> JWT 안에는 비밀번호와 같은 민감한 정보는 포함시키면 안됨)
JWT 사용 흐름
1. Client 가 username, password 로 로그인 성공 시
a. 서버에서 "로그인 정보" → JWT 로 암호화(Secret Key 사용)
b. 서버에서 직접 쿠키를 생성해 JWT를 담아 Client 응답에 전달 (JWT 전달방법은 개발자가 정함)
c. JWT가 Client 의 브라우저 쿠키 저장소에 저장됨
2. Client 가 JWT 통해 인증 할 때
a. 서버는 API 요청 올 때마다 쿠키에 포함된 JWT를 찾아서 사용
i. Client 가 전달한 JWT 위조 여부 검증(Secret Key 사용) ii. JWT 유효기간이 지나지 않았는지 검증 iii. 검증 성공시, JWT에서 사용자 정보를 가져와 확인
필터란 무엇인가?
- Web 애플리케이션에서 관리되는 영역으로 Client로 부터 오는 요청과 응답에 대해 최초/최종 단계의 위치이며 이를 통해 요청과 응답의 정보를 변경하거나 부가적인 기능을 추가
- 주로 범용적으로 처리해야 하는 작업들, 예를들어 로깅 및 보안 처리에 활용
또한 인증, 인가와 관련된 로직들도 처리 가능.
Filter를 사용하면 인증, 인가와 관련된 로직을 비즈니스 로직과 분리하여 관리할 수 있다는 장점이 있다.
Filter Chain
필터는 이런 체인 형식으로, 여러개가 묶여서 처리 된다.
Spring Security Filter Chain
Spring Security는 FilterChainProxy를 통해서 상세로직을 구현. (Proxy: 가짜, 대리인)
Form Login 기반 인증
Form Login 기반 인증은 인증이 필요한 URL 요청이 들어왔을 때 인증이 되지 않았다면 로그인 페이지를 반환
Spring Security Filter Chain 내부 동작 방식
UsernamePasswordAuthenticationFilter란,
Spring Security의 필터인 AbstractAuthenticationProcessingFilter를 상속한 Filter다. (확인해서 인증 처리하는 녀석)
- 인증 과정
1. 사용자가 username과 password를 제출하면 UsernamePasswordAuthenticationFilter는 인증된 사용자의 정보가 담기는 인증 객체인 Authentication의 종류 중 하나인 UsernamePasswordAuthenticationToken을 만들어 AuthenticationManager에게 넘겨 인증을 시도합니다.
2. 실패하면 SecurityContextHolder를 비웁니다.
성공하면 SecurityContextHolder에 Authentication(UsernamePasswordAuthenticationToken)를 세팅(저장)합니다.
SecurityContext
- SecurityContext는 인증이 완료된 사용자의 상세 정보(Authentication)를 저장
- SecurityContext는 SecurityContextHolder 로 접근 할 수 있다.
// 예시코드
SecurityContext context = SecurityContextHolder.createEmptyContext();
Authentication authentication = new UsernamePasswordAuthenticationToken(principal, credentials, authorities);
context.setAuthentication(authentication); // SecurityContext 에 인증 객체 Authentication 를 저장
SecurityContextHolder.setContext(context);Authentication --> 토큰?
- principal : 사용자를 식별
(Username/Password 방식으로 인증할 때 일반적으로 UserDetails 인스턴스) - credentials : 주로 비밀번호, 대부분 사용자 인증에 사용한 후 비움
- authorities : 사용자에게 부여한 권한을 GrantedAuthority로 추상화하여 사용 -> 권한에 따른 요청 허락유무 기능에 사용.
UserDetailsService
- username/password 인증방식을 사용할 때, 사용자를 조회하고 검증한 후 UserDetails를 반환한다.
(Custom하여 Bean으로 등록 후 사용 가능)
UserDetails (Principal에 들어가있음)
- 검증된 UserDetails는 UsernamePasswordAuthenticationToken 타입의 Authentication를 만들 때 사용됨.
- 해당 인증객체는 SecurityContextHolder에 세팅됨.
(Custom하여 사용 가능)
Spring Security 로그인
로그인 처리 과정
관련 포스팅
