[Spring Security] Session와 Token(Access Token & Refresh Token)

💡 쿠키와 세션

세션 기반 & 토큰 기반 자격 증명

HTTP 프로토콜은 무상태성(Stateless)으로 인해 클라이언트의 Request에 대한 서버의 Response를 수신하게 되면 연결을 끊는 비연결성(Connectionless)의 특징을 가진다.

클라이언트가 로그인 인증을 위해 요청을 보내더라도 무상태성때문에 로그인의 상태가 유지되지 않는다. 이러한 단점을 보안하기 위해 쿠키와 세션을 사용한다고 학습했다.

세션 기반 자격 증명

세션은 클라이언트의 Request에 자동으로 서버에 전달되는 쿠키에 세션 Id가 담겨 전달되는 방식으로 사용되지만 브라우저에 저장되는 쿠키와는 달리 서버에서 관리된다.

이 말은 인증된 사용자의 정보를 서버의 세션 저장소에서 관리하고 클라이언트에겐 해당 사용자를 구분할세션 Id만 전달하는 것이다.

☝️즉, 세션 기반 자격 증명 방식이란 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식임을 알 수 있다.

세션 기반 자격 증명의 특징

• 인증된 사용자의 정보를 서버의 세션 저장소에서 관리
• 서버로부터 생성된 세션ID는 고유한 값을 가지며, 클라이언트의 쿠키에 저장되어 있다가 resquest시 쿠키가 전송되는 시점에 함께 전송되며 인증된 사용자임을 증명하는 수단으로 사용된다.
• 세션ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용
• 서버에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리
• 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.

🧐
하나의 서버를 사용할 때에는 문제가 없지만 서버가 여러개로 확장되었을 때 HTTP 요청을 받는 서버를 지정해 요청을 보낼 수 없다.
만약 내가 보낸 요청을 받은 서버의 세션 저장소에 나의 정보가 담겨져 있지 않다면 세션 불일치 문제가 발생하는 것!
☝️ 세션 불일치 문제는 외부 저장소로 분리하는 작업 등을 통해 보완한다.

• 세션 데이터가 많아질수록 서버의 부담이 가중된다.
• SSR 방식의 애플리케이션에 적합한 방식
•  

토큰 기반 자격 증명 방식🪙

토큰🪙(Token)

비용을 지불하면 받을 수 있는 토큰은 이미 비용을 지불했기 때문에 사용에 대한 권한을 가진 것이다.

☝️이처럼 애플리케이션 보안 측면에서의 토큰은 사용자의 자격 증명 정보가 포함되어 있다고 생각하자.

서버에 세션 정보(사용자 증명 정보)를 저장해놓고, 클라이언트의 요청을 할 때마다 세션 ID를 서버에 보내 사용자의 상태를 유지하는 세션 기반 자격 증명 방식과는 달리 토큰 기반 자격 증명 방식은 클라이언트의 요청 시마다 사용자의 자격 증명 정보를 보내는 것이다.

토큰 기반 자격 증명 방식의 특징

• 토큰에 인증된 사용자 정보를 저장하기 때문에 서버에서 별도의 관리를 하지 않는다.
• 생성된 토큰은 클라이언트의 Request를 보낼 때, header에 포함되어 사용자를 증명하는 수단으로 사용된다.
• Request마다 사용자 정보가 저장된 토큰을 보내야하므로 세션에 비해 더 많은 네트워크 트래픽을 사용한다.
• 서버에서 토큰을 관리하지 않기 때문에 보안성 측면에서 조금 더 불리하다.
• 사용자의 인증된 정보를 서버에서 관리하지 않기 때문에 서버의 확상성 면에서 유리하고 세션 불일치와 같은 문제가 발생하지 않는다.
• 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.
• CSR 방식의 애플리케이션에 적합한 방식

🧐단, 토큰에 저장된 사용자 정보는 토큰의 특성 상 암호화가 되지 않기 때문에 탈취될 위험이 크다. 따라서 민감한 정보를 포함시키지 않도록 주의해야 한다.
☝️ 토큰의 무효화 문제는 토큰의 만료기간은 짧게 설정해 보완한다.(Refresh Token을 도입) 

❗❗로그인 시 토큰이 더 나은 이유? (세션 방식보다 토큰이 더 나은 이유?)

• 세션 
  • 클라이언트당 정보를 따로 DB에 저장해주어야 한다.
  • (클라이언트에게는 계속 연결된걸로 보이지만) 끊임없이 Session ID를 요청하고 응답해야함 (DB에 접속)
• 토큰
  • 로그인 시 처음에만 회원 DB를 확인하고 확인 토큰 (Access Token)부여
  • 추후 로그인하여 요청/응답 시행시 다시 DB에 접속할 필요가 없이 Token에 부여된 정보만으로 로그인 연결을 보여줄 수 있음. 

Refresh Token 인증 과정

 

 

1. 사용자가 ID , PW를 통해 로그인.

2. 서버에서는 회원 DB에서 값을 비교

3~4. 로그인이 완료되면 Access Token, Refresh Token을 발급한다. 이때 회원DB에도 Refresh Token을 저장해둔다.

5. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보낸다.

6~7. Access Token을 검증하여 이에 맞는 데이터를 보낸다.

8. 시간이 지나 Access Token이 만료됐다.

9. 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다.

10~11. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.

Tip

Access Token 만료가 될 때마다 계속 과정 9~11을 거칠 필요는 없다.
사용자(프론트엔드)에서 Access Token의 Payload를 통해 유효기간을 알 수 있다.
따라서 프론트엔드 단에서 API 요청 전에 토큰이 만료됐다면 곧바로 재발급 요청을 할 수도 있다.

12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.

13. 서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해준다.

14. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청 응답을 진행한다. 

 

출처

🌐 JWT 토큰 인증 이란? (쿠키 vs 세션 vs 토큰)

🌐 Access Token & Refresh Token 원리