💡 Access Token+ Refresh Token을 이용한 인증 Access Token을 이용한 인증 방식의 문제는 해커에게 탈취당할 경우 보안에 취약하다는 점 토큰의 유효기간을 짧게 하면 사용자는 로그인을 자주 해야해서 번거롭고, 길게하면 보안이 취약해지기 때문에 이를 해겨라고자 나온 것이 Refresh Token Refresh Token은 Access Token과 같은 형태의 JWT Refresh Token은 Access Token보다 긴 유효기간을 가지고, Access Token이 만료됐을 때, 새로 발급해주는 열쇠가 됨 → ex) Refresh Token의 유효기간이 2주, Access Token의 유효기간이 1시간이라면 2주 동안 Access Token이 만료되는 1시간 주기마다 Access..

💡 Access Token을 이용한 인증 JWT JSON Web Token의 약자 인증에 필요한 정보들을 암호화시킨 토큰을 말하며 Access Token으로 사용됨 JWT를 생성하기 위해선 Header, Payload, Verify Signature 객체를 필요로 함 Header 토큰의 타입을 나타내는 typ와 암호화할 방식을 정하는 alg로 구성됨 { 'alg': 'HS256', 'typ': 'JWT' } Paylod 토큰에 담을 정보를 포함 하나의 정보 조각을 클레임이라 부름 클레임의 종류 → Registered, Public, Private 3가지 존재 보통 만료 일시, 발급 일시, 발급자, 권한 정보 등을 포함 { 'sub': '1234567890', 'name': 'John Doe', 'admi..

💡 세션과 쿠키를 이용한 인증 인증 순서 사용자가 로그인을 함 서버에서 계정 정보를 읽어 사용자 확인 사용자에게 고유한 ID 값 부여하여 세션 저장소에 저장 이와 연결되는 Session ID를 발급 서버에는 HTTP 응답 헤더에 발급된 Session ID를 같이 보냄 이후 매 요청마다 HTTP 요청 헤더에 Session ID가 담긴 쿠키를 같이 보냄 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옴 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줌 장점 사용자의 정보는 세션 저장소에 저장되고, 쿠키는 그 저장소를 통과할 수 있는 출입증 역할을 함 → 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체에는 유의미한 값을 갖고 잇지 않아서 쿠키에 사용자 정보를 담아 인증..

💡 Form Login 개념 & 사용법 사용자가 Server에 특정 URL을 요청하였을 때 해당 URL이 인증이 필요할 경우 Server는 Login 페이지를 return 사용자는 username(ID)와 password를 입력하여 로그인 요청을 하면 Post mapping으로 해당 데이터가 서버에 전송 Server는 해당 로그인 정보를 확인합니다. 해당 유저 정보가 존재한다면 Session과 Token을 생성하고 저장

Filter → 서블릿 컨테이너의 Filter는 Dispatch Survlet으로 가기 전에 먼저 적용 → client가 http request를 보낼 때 먼저 filter를 거친다는 뜻을 내포하는 그림 → client가 보낸 http request는 여러 개의 filter를 거쳐가게 됨 → 이러한 filter들이 여러 개로 엮여서 chain의 형태를 띈다고 하여 위의 형태를 Filter chain 이라고 부름 → 모든 Request들은 Filter chain을 거쳐야지 servlet에 도착함 → Spring Security는 Filter chain 사이에 DelegationFilterProxy 라는 것을 끼워넣어서 보안 정책을 수행함 ⇒ 경우에 따라 보안 정책을 달리해야하므로 filter의 적용을 다르..

WebSecurityConfigureAdapter → SecurityFilterChain filterChain(HttpSecurity http)로 변경되었음