Spring Security를 사용해서 로그인 구현하기 - JWT와 세션(0)

Authentication vs Authorization

 

Atuhentication: 인증
Authorization: 권한 부여

 

웹 사이트에 로그인 하는 것을 Authentication이라고 한다. 한번 로그인을 한 후에는 로그인 상태가 유지되어야 한다.
이 유지하는 역할을 하는 것이 Authorization이다.

 

권한 부여를 통해 로그인 상태의 사용자만 사용할 수 있는기능을 사용할 수 있게 한다.
어떤 요청마다 로그인을 할 수 없는 노릇이니 로그인 상태를 유지시키는 기술이 필요하다

-> 여기서 세션이나 JWT 활용

 

 

대표적으로 사용자의 인증/인가를 처리할 때 사용하는 방식은 다음과 같이 3가지가 있다

1. 쿠키 방식
2. 세션 방식
3. JWT 토큰 방식

---

쿠키

 

클아이언트가 인증정보 관리 (stateless)

쿠키 인증 방식은 쿠키에 사용자의 인증 정보를 담아서 인증하는 방법이다.

인증/인가 flow

1. 클라이언트가 서버에 첫 로그인 인증 요청을 보내면, 서버에서 응답으로 쿠키에 사용자 인증 정보를 담아서 보낸다.
2. 서버에서 응답한 쿠키를 클라이언트에 저장하고, 인증/인가 요청 시마다 서버로 요청한다.

 

장점

1. 인증/인가의 작업이 쉽고, 간단하다
2. 사용자의 인증 정보를 클라이언트가 관리하기 때문에 서버 부하가 적다
3. 인증 상태를 서버가 관리하지 않고 매번 클라이언트의 인증 정보를 담은 쿠키의 요청을 받을 때 처리하므로 stateless

 

단점

1. 클라이언트가 쉽게 쿠기에 담긴 인증 정보를 위조할 수 있다.
2. 쿠키의 데이터 크기가 제한적이고, 또 크기가 커진다면 네트워크 부하가 심해진다

1번의 단점이유로 쿠키 방식을 사용하지 않는 치명적인 이유라고 할 수 있다!!

쿠키 방식은 보안상 상당히 위험하다...!!

---

세션

 

서버가 인증정보 관리 (stateful)

세션으로 사용자의 인증정보를 관리하는 방식

인증/인가 flow

1. 클라이언트가 서버에 첫 로그인 인증 요청을 보내면, 서버에서 인증 정보를 저장하고 sessionID를 클라이언트에게 제공
2. 서버에서 받은 sessionID로 서버에게 인증/인가 요청을 하여 서버에 sessionID에 해당하는 인증 정보로 인증/인가 처리

 

장점

• 서버에서 인증 정보를 관리하기 때문에 보안성 훨씬 안전하다

 

다음과 같은 추가 기능을 제공

1. 한 사용자의 디바이스별 인증을 관리할 수 있다

• pc로 접속 시 다른 기기의 접근을 막을 수 있다.
• 여러 디바이스에서 접속중일 때 특정 디바이스의 유저를 로그아웃하게 할 수 있다.
  
  

2. 하나의 계정 공유를 관리할 수 있다.

• 넷플릭스처럼 계정 공유의 수도 제한 할 수 있다.
  
  

3. 비정상적인 접근 신고가 들어오면, 서버에서 판단하여 해당 세션을 삭제해서 바로 로그아웃시킬 수 있다.

 

 

그럼 서버는 어느 곳에 sessionID같은 상요자 인증 정보를 관리할까?

 

크게 3가지로 분류할 수 있다

1. 메모리
2. 하드디스크
3. DB

 

메모리 영역에서 관리하는 경우

장점

• 메모리영역에서 사용자 인증정보를 관리하면 속도가 빠르다

 

단점

• 사용자가 동시에 sesstionID로 인증 요청을 많이 보내면 서버 메모리 부족해질 수도 있다.
• !!서버를 껐다가 켰을 때 session정보가 휘발된다는 치명적인 점

 

하드디스크에서 관리하는 경우

장점

• DB보다 속도가 빠르다

 

단점

• 메모리보다 속도가 느리다.

 

메모리, 하드디스크 영역에서 관리하게 됐을 때의 공통적인 문제점.

scale-out을 사용하여 서버가 여러 대 존재하여 로드 밸러싱을 사용할 때,

한 사용자가 로그인한 후 다음 인가 요청 시 로드 밸런싱으로 인해

사용자가 로그인한 서버가 아닌 다른 서버로 요청이 보내지면 다시 재로그인 해야한다.

로드밸런싱 시에 이러한 문제가 발생하여 추가적인 서버 부하와 사용자에게 불편함을 줄 수 있다.

 

그렇다면 로드밸런싱으로 인해 나타나는 문제를 해결하기 위해서 하나의 DB에 세션목록을 관리하면 어떨까?

서버DB에서 사용자 인증정보를 관리하는 방법

장점

• 메모리와 하드디스크의 단점을 해결

 

단점

• 속도가 느리다

 

그래서 인증/인가 방식으로 세션을 이용한다면 보통은 서버 DB로 사용자 인증 정보를 관리한다.

하지만 로그인한 모든 유저의 인증 정보를 DB에 관리해야하므로 무겁고,

매 인증마다 DB를 거쳐 인증 정보를 seelct해야하므로 연결 비용이 크다!!

---

JWT 토큰 방식

 

클라이언트가 인증정보 관리(stateless)

토큰의 종류에는 jwt이외에도 여러 토큰이 존재하지만 jwt토큰이 간단하고 레퍼런스가 많다.

 

인증/인가 flow

1. 클라이언트가 서버에 첫 로그인 인증 요청을 보내면, 서버에서 응답으로 token을 담아서 보낸다.
2. 서버에서 응답한 token을 클라이언트에서 저장하고, 인증/인가 요청 시마다 서버로 요청한다

 

기본적으로 클라이언트가 인증정보를 관리하므로 쿠키 인증 방식과 flow가 비슷

 

그렇다면 쿠키와 jwt는 어떻게 다를까?

• !!쿠키가 아닌 jwt토큰을 매캐체로 인증한다는 것
• 서버에서 '토큰 검증'이 이루어진다는 것.
• 쿠키보다는 보안적으로 안전하게 관리

 

어떻게 쿠키보다 보안적으로 안전하다는 걸까?

jwt에 대해 알아야한다.

jwt를 간단하게 설명하면, 사용자의 인증 정보와 서버의 secretKey로 서버가 생성한 token이다.

 

'서버의 secretKey로 서버가 생성한 token!!

클라이언트가 token을 저장하고 인가 요청 시에 발급 받은 token으 사용하여 요청을 보내기 때문에 token을 클라이언트가 관리한다는 점은 쿠키 인증방식과 비슷하겠지만,

!!서버에서도 해당 token에 대한 secretKey를 가지고 있다는 점에서 쿠키 인증 방식과 다르다

 

'token 검증' 이란걸 하는 이유

요청으로 온 token이 서버에서 발급한 token인지 검증하는 단계이다.

이때, 요청으로 온 token의 secretKey가 다르면 위조, 변조 된 token이라고 판단하여 인증에러를 발생

 

이런 검증 단계를 거치니까 쿠키보다 보안상 훨씬 안전하겠죠??

 

세션방식과 비교해서는 기본적으로 클라이언트가 token을 관리하므로 서버 부하가 비교적 덜하다는 장점이 있다.

하지만 token을 검증하는 것뿐이지 token을 관리하는 것은 아니기 때문에 세션보다 보안상 취약하고

비정삭적인 유저라고 판단 시 token을 만료하거나, 디바이스별 제어 등 세션에서 가능했던 부분들이 불가능하다.

위에서 설명한 token은 모두 access token을 의미하고 refresh token을 사용해서 보안을 강화할 수는 있지만

세션 방식에 비해서는 완벽하지 못하다.

 

토큰 인증/인가 방식 정리

장점

• 클라이언트가 인증 정보를 관리한다는 점에서 쿠키 인증방식과 비슷하지만, 쿠키 대신 jwt토큰을 사용하고, 서버에서 해당 토큰을 검증!! 하는 단계를 거쳐 보안상 쿠키 방식보다 뛰어나다.
• 서버 부하가 비교적 덜 하다

 

단점

• 보안이 세션방식보다는 취약하고 세션 방식의 여러 기능을 사용할 수 없다

 

---

참고자료

https://ksh-coding.tistory.com/113