서버 인증 (세션/쿠키 기반)

인증은 왜 필요할까?

A와 B의 유저가 은행 사이트에서 각 본인의 잔액을 확인하기 위해 로그인을 하고 본인들의 잔액을 확인할 수 있습니다. 여기서 로그인은 A와 B를 구분하는 인증으로 볼 수 있습니다. 또한, A의 잔액을 B나 다른 사용자에게 노출시키면 안되므로 보안으로도 볼 수 있습니다. 현재 가장 많이 사용하는 통신 방식은 HTTP 방식입니다. HTTP의 특징으로 stateless가 있습니다. 이러한 특징으로 인해, 만약 은행 사이트에 인증과 관련된 내용이 없다면 로그인을 한 뒤에 메인 페이지로 이동했을 시, 정보가 사라져 어느 사용자인지 알 수 없습니다. 따라서 사용자마다 다른 정보를 노출하고 저장할 때, 인증은 필수적으로 가져가야 합니다. 아래에서는 다양한 인증 방식과 장단점을 설명합니다.

헤더에 사용자 정보를 추가하여 전달

사용하면 안되는 방식입니다. 로그인 이후에도 다른 페이지를 이동할 때마다 사용자의 정보를 헤더에 추가하여 서버에 전달하는 방식입니다. 개발 초기에 내부에서 테스트를 진행할 때나 사용할 수 있는 방식으로 이러한 방식으로 실제 서비스 운영이 된다면 사용자의 개인정보를 그대로 노출시켜 보안 문제를 발생시킵니다.

장점

1. 인증 방식을 고려할 필요가 없음

2. 편함

단점

1. 보안에 매우 취약

2. 요청이 올 때마다 서버는 전달받은 데이터로 해당 유저가 맞는지 검증해야 하므로 비효율적

세션/쿠키 기반 인증 방식

서버의 세션과 사용자 쿠키를 기반으로 하는 인증 방식입니다.

인증 방식은 아래의 단계와 같습니다.

1. 클라이언트가 로그인을 위해 해당 정보를 서버에 전달
2. 서버는 정보를 읽어 사용자를 확인하고 로그인 성공 시, 사용자를 식별할 수 있는 고유한 세션 ID를 생성하고 이를 메모리나 DB에 저장
   1. 저장하는 곳을 세션 저장소라고 하고 보통 Redis를 많이 사용함
3. 서버는 요청의 결과값으로 세션 ID를 사용자에게 전달
4. 세션 ID를 전달받은 사용자는 쿠키에 해당 값을 저장
5. 이후 다른 페이지 이동이나 사용자 인증이 필요할 때, 헤더에 해당 쿠키를 실어서 전달
6. 서버는 쿠키를 받아서 세션 저장소에 저장이 된 쿠키(세션ID)인지 확인
7. 유효한 쿠키(세션ID)일 경우, 요청받은 데이터를 반환

Redis를 세션 저장소로 사용한다면 세션ID가 서버의 메모리에 저장이 됩니다. 만약 서버 확장 시, 모든 서버가 세션 저장소에 접근할 수 있도록 중앙 세션 저장소 관리가 필요합니다.

장점

1. 쿠키가 포함된 요청이 외부에 노출되어도 쿠키(세션ID)는 유의미한 값을 갖고 있지 않기 때문에 쿠키 자체로 큰 문제를 발생시키지 않음

2. 요청을 주는 각 사용자마다 고유의 세션ID가 발급되어 일일이 회원정보를 확인할 필요 없음

단점

1. 장점 1번에서 쿠키 자체는 유의미하지 않아 노출되도 큰 문제가 없다고 했으나, 사용자 A가 보낸 요청을 해커가 탈취(하이재킹)하여 해당 쿠키로 서버에 변질된 내용으로 HTTP요청을 보내면 서버는 해커의 요청을 A 사용자로 인식하게 됨

• 이를 방지하기 위해 세션의 유효시간을 추가하거나 HTTPS를 사용해 탈취해도 안의 정보를 읽기 힘들게 만들 수 있음

2. 서버에서 세션 저장소를 사용하므로 추가적인 저장공간을 필요로 함

3. 중앙 세션 저장소 관리가 없으면 시스템 확장이 어려움

4. 중앙 세션 저장소에 장애가 발생하면 인증 전체가 문제가 될 수 있음

만약 세션을 사용하지 않고 쿠키만으로 인증을 한다면?

사용자가 로그인 시, 서버는 ID, PWD와 같은 값을 암호화 또는 인코딩으로 변환하여 사용자에게 전달하고 사용자는 이를 쿠키에 저장합니다. 그리고 인증이 필요할 때마다 이 쿠키를 헤더에 담아서 서버에 요청을 하고 서버는 해당 쿠키를 복호화 또는 디코딩으로 풀어 사용하게 됩니다. 여기서 문제는 쿠키가 유의미한 값을 갖게 되기 때문에 외부에 노출이 된다면 헤더에 사용자 정보를 전달하는 방식과 같은 문제를 띄게 됩니다.