[CS] 세션 기반 인증과 토큰 기반 인증 (+인증, 인가)

세션 기반 인증과 토큰 기반 인증에 대해 알아보기 전에 , 인증과 인가의 개념부터 알아보자 ! 

 

1️⃣ 인증 (Authentication)

인증은 사용자 또는 디바이스 등의 신원 정보를 확인하는 과정으로, 쉽게 말하자면 로그인이라고 볼 수 있다.

로그인 페이지에서 아이디와 비밀번호를 입력해서 제출하면, 일치할 경우에만 인증 절차에 성공한다.

따라서 클라이언트가 자기 자신이라고 주장하고 있는 사용자가 맞는지를 검증하는 과정이다.

 

2️⃣ 인가 (Authorization)

인가는 인증 작업 이후에 행해지는 작업으로 사용자 또는 디바이스 등이 어떤 리소스에 접근할 수 있는지,

어떤 동작을 수행할 수 있는지 등을 검증하는 것이다. 따라서 인증된 사용자에 대한 자원에 대한 접근 확인 절차를 의미한다.

내가 작성한 글은 나만 수정할 수 있고, 내가 다른 사람들의 글은 수정할 수가 없는데,

타인의 리소스에 대해서는 인가되어 있지 않기 때문이다.

 

세션과 토큰 기반 방식을 얘기하는데 왜 인증, 인가를 얘기하냐면 이는 HTTP 비상태성 특징 때문이다 !

3️⃣ HTTP의 비상태성 (Stateless)

HTTP는 비상태성 이라는 특성을 갖는데, 각 요청은 서로 독립적이며 서버는 이전 요청의 상태나 정보를 기억하지 않는다는 특징을 가진다.

예를 들어서, 클라이언트가 서버에 A라는 요청을 보내고, B라는 요청을 또 보냈을때 서버는 "이 요청이 같은 사용자로부터 온 것" 이라는 사실 조차 알지 못한다. 따라서 로그인을 성공하더라도 서버는 그 사용자가 누구인지 기억하지 못한다. 그래서 매 요청마다 로그인 정보를 다시 보내야 한다는 불편함이 생기기 때문에, 이 문제를 세션 또는 토큰을 사용해서 해결할 수 있다. 

 

 

🍒 세션 기반 인증 

세션 기반 인증은 사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식이다.

✅ 절차

1. 사용자가 로그인 요청을 서버로 보낸다.

2. 서버는 로그인 요청을 인증하고 세션 정보를 데이터베이스로 전송해 저장한다. 

3. 서버는 사용자에게 세션 ID를 포함하는 쿠키를 포함해서 사용자에게 응답을 보낸다.

4. 사용자는 새로운 요청을 전송할 시, 쿠키를 포함한 새로운 요청을 서버로 전송한다. 

5. 서버는 데이터베이스에서 사용자가 요청을 전송할 때 보낸 쿠키에 포함되어 있는 세션 ID를 확인한다.

6. 서버는 데이터베이스에 사용자의 세션 정보가 있음을 확인하고, 사용자가 요청한 페이지를 사용자에게 보낸다.

 

😇 장단점

장점	단점
계정이 손상된 것으로 의심되는 경우 세션 ID를 즉시 비활성화하여 사용자가 즉시 로그아웃되도록 할 수 있다.	세션 방식은 서버에 저장되므로 서버에서 사용자가 보낸 세션 ID를 검색해야 한다. 이로 인해 사용자의 세션이라는 상태가 생기기 때문에 추후 서버를 수평 확장할 때 Scalability 문제가 발생할 수 있다.
서버에 저장하기 때문에 관리가 매우 편하고 효율적이다.	세션 ID를 전송할 때, 쿠키를 사용하는데 쿠키가 사이트 간 위조 공격에 노출될 수 있다.
구현이 명확하여 실제 서버에서 로그인 상태를 확인하기 유용하다.	서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 클라이언트 수가 많으면 메모리나 DB에 부하가 심하다.

 

🔥 따라서 세션을 사용하게 될 경우 이러한 단점들로 인해 관리하는 것이 어렵기 때문에 고안된 것이 토큰 기반 인증이다.

 

🍑 토큰 기반 인증

토큰 기반 인증의 방법으로 많은 웹 서버들은 JWT를 사용한다. 토큰 기반 인증 방식과 세션 기반 인증 방식의 가장 큰 차이점은 유저의 정보가 서버에 저장되지 않으며, 서버는 유저 인증을 위해 많은 일을 하지 않아도 된다.

✅ 절차

1. 유저가 서버에 로그인 요청을 보낸다.

2. 서버는 데이터베이스에 저장된 유저의 인증정보를 확인한다.

3. 인증에 성공하면, 서버는 유저에 대한 권한 정보를 서버의 비밀키와 함께 토큰을 생성한다.

4. 서버는 Authorization 헤더에 토큰을 담아 클라이언트에 전달한다.

5. 클라이언트는 전달받은 토큰을 브라우저의 세션 스토리지 or 로컬 스토리지에 저장한다.

6. 클라이언트가 서버로 리소스를 요청할 때, Authorization 헤더를 통해 토큰이 함께 전달된다.

7. 서버는 전달받은 토큰을 서버의 비밀키로 검증한다. 이를 통해, 토큰이 위조되었는지, 유효기간이 지나지 않았는지 등을 확인할 수 있다. 

8. 토큰이 유효하다면, 유저의 요청에 대한 응답 데이터를 전송한다. 

 

😇 장단점

장점	단점
멀티 디바이스 클라이언트를 대응하는데 부담이 적다. 클라이언트가 토큰 정보를 갖고 있기 때문에 서버의 부담이 적다.	상태를 기억하지 않기 때문에 통제할 수 없다.
클라이언트 세션 관리에 대한 서버의 메모리 부담을 줄일 수 있다.	토큰 정보가 탈취될 수 있어도 무효화할 수 없다. 보안에 취약하다.
다양한 도메인에 대응하는데 부담이 적다.	토큰 인증을 위해 Database에서 매번 조회해야 하므로 DB 성능 부하가 있을 수 있다.

 

 

🔥 결론

JWT는 세션 ID에 비해 비대하므로 훨씬 더 많은 네트워크 트래픽을 사용한다. 또한 세션의 경우 모든 인증 정보를 서버에서 관리하기 때문에 보안 측면에서 조금 더 유리하다. 그럼에도 불구하고 대부분의 서비스가 토큰 기반 인증을 사용하는 이유는 바로 확장성 때문이다. 토큰 기반 인증 방식의 경우 서버가 직접 인증 방식을 저장하지 않고, 클라이언트가 저장하는 방식을 취하기 때문에 세션 불일치 문제로부터 자유로워 높은 확장성을 가질 수 있다. 또한 토큰 기반 인증의 경우에는 유저의 수가 얼마가 되던 서버의 부담이 증가하지 않기 때문에, 서버의 부담 측면에서도 세션 기반 인증 방식보다는 토큰 기반 인증 방식이 조금 더 유리함을 알 수 있다.