[Web] 인증과 인가란? - 쿠키와 세션에 대해서 알아보자!

🌱 들어가기 전

테코톡에서 진행한 인증과 인가 관련 자료들을 바탕으로 글을 작성하였습니다 :D

---

🌱 인증 (Authentication)

보호된 리소스에 접근하는 것을 허용하기 이전에, 등록된 유저의 신원을 입증하는 과정이다.

식별 가능한 정보를 바탕으로, 서비스에 등록된 유저의 신원을 입증하는 과정!

ex) 어떤 사이트에서 글을 작성하기 위해서는 해당 사이트의 회원이어야 한다.

'로그인하지 않은 회원'의 경우 글을 작성할 수 없으며, 해당 회원의 로그인 여부를 확인하는 과정이 '인증'이다.

 

 

🌱 인가 (Authorization)

요청된 리소스에 접근할 수 있는 권한이 있는 인증된 유저인지 입증하는 과정이다.

ex) 로그인까지는 완료했는데, 해당 사용자는 그 사용자가 작성한 글만 제거하거나 수정이 가능하다.

같은 권한의 다른 사용자가 작성한 글을 수정하거나 삭제할 수 없다.

 

인증이 인가보다 더 선행되는 과정이다.

일반적으로 인증 과정이 있는 다음에 인가 과정에 있는 것이 일반적이다.

'인증되었지만 권한이 없는 상태'는 인가되지 않은 상태지만, '인가되었지만 인증되지 않았다'는 존재할 수 없는 상황이다.

 

 

💬 HTTP Status Code - 401 vs 403

상태 코드에 대해 처음 공부했을 때 가장 헷갈리던 개념이었는데, 인증과 인가와 밀접한 관련이 있다.

401번의 경우 Unauthorized, 403의 경우 Forbidden인데, 인증이 401, 인가가 403에 대한 상태 코드가 된다.

401 (Unauthorized)	403 (Forbidden)
인증 관련	인가 관련
인증되지 않았거나 인증 정보가 부족한 경우 (사용자가 로그인을 안 함)	권한이 없는 자원을 요청하는 경우 (일반 사용자가 관리자 권한 기능을 사용할 때)

- 참고로, 403이 내려왔다는 것은 '어떠한 리소스가 존재하지만 해당 리소스는 특정 사용자만 볼 수 있어요!' 라고 말하는 것과 동일하기 때문에, 이를 다르게 해석하면 해당 URI은 어떠한 리소스가 있음을 내포하는 것으로도 의미한다.

그렇기 때문에 해당 리소스가 중요한 정보라면, 403 대신에 아예 404을 내려줘서 자원의 존재 자체를 숨기는 방법도 있다.

 

---

🌱 HTTP stateless - 상태를 어떻게 가지게 할까?

HTTP의 특징으로 크게 stateless (상태가 없음) 와 connectionless (연결성이 없음)를 뽑을 수 있다.

 

stateless의 경우 서버가 클라이언트의 각 요청을 구분하지 않는다는 것이다.

방금 전에 발송된 요청과 지금 발송한 요청에 대해 어떠한 연관관계를 가지지 않으며, 다중의 서버가 존재할 때 클라이언트의 요청에 대해서 어떤 서버가 응답하더라도 상관이 없어진다.

 

connectionless의 경우 클라이언트의 요청 이후 서버가 응답을 완료하면, 바로 TCP / IP 연결을 끊어서 해당 커넥션을 유지하지 않는다는 것이다. 이러한 비연결성으로 인해 매 요청마다 TCP / IP를 새로 맺어야 하기 때문에 낭비가 발생할 수 있기는 하다. (물론 이에 대해서는 Persistent Connection을 통해서 어느 정도 해소했지만)

 

위의 특징을 생각해보자.

서버는 클라이언트의 요청을 구분하지 못하기 때문에, 사용자별로 어떠한 요청을 구분하는 게 이론적으로 불가능하다.

하지만 우리는 로그인도 하고, 글도 작성하고 그러고 있다. 여기에 '인증' 개념이 들어가기 때문이다.

지금부터 인증을 처리하는 방법과 다양한 인증 관련 정보들을 함께 살펴보자.

 

---

🌱 1. 인증하기

The HTTP Authorization request header can be used to provide credentials that authenticate a user agent with a server, allowing access to a protected resource.

HTTP request header 중에 'Authorization' 필드의 경우 클라이언트가 서버에게 본인의 자격 증명을 제공하여, 보호된 리소스에 액세스할 수 있도록 만들 때 사용한다. 말은 어렵지만, 관습적으로 Authorization 헤더에는 인증 정보가 들어간다는 것이다.

 

인증을 진행하는 방법은 다양하게 있지만, 가장 간단한 Basic 인증 방법을 떠올려보자.

Authorization: Basic <credentials>

여기서 credentials 부분에는 Base64로 인코딩된 A:B 정보를 보낸다.

다만, base64로 디코딩이 바로 가능하기 때문에 사실 민감한 정보는 담지 않는 것이 좋다.

 

가장 간단한 방식인 Basic 인증 방식을 사용하게 된다면, 'Basic + Base64로-인코딩된(아이디:비밀번호)' 정보가 들어간다.

서버에서는 해당 정보를 받아 디코딩하여 사용자 정보 파싱하고, 실제로 등록된 유효한 사용자인지 체크하여 200 or 401을 내려준다.

 

하지만, 이렇게 단순히 Header 정보를 사용하게 되면 권한이 필요한 행위가 있을 때 매번 인증을 해야 하기 때문에 트래픽이 많은 서비스에서는 굉장히 부담이 될 수 있다.

 

---

 

🌱 2. 인증 유지하기

매변 인증하지 않고, 인증 정보를 유지할 수 없을까?

이를 위해서 브라우저의 힘을 빌려, '로컬 스토리지, 세션 스토리지, 쿠키' 등의 다양한 방법을 사용할 수 있다.

 

 

🍪 쿠키 (Cookie)

쿠키는 브라우저에 저장되는 만료 기간이 있는, Key-value로 이루어진 데이터 파일.

Stateless한 HTTP에서 상태를 가지고 있는 것처럼 인증 정보를 유지하기 위해서 사용한다.

자바스크립트에서 document.cookie를 사용하면 쿠키에 대한 정보를 쉽게 취득할 수 있기 때문에 XSS 문제가 발생한다.

💬 XSS: 악의적인 목적을 가진 제3자가 악성 스크립트를 삽입하여 의도하지 않는 명령을 실행시키거나 세션 등을 탈취할 수 있는 취약점.

 

그래서 보통 쿠키를 사용할 때는 아래와 같이 HttpOnly 옵션을 켜주는 것이 좋다.

private void addCookie(final HttpServletResponse response, final String token) {
    Cookie cookie = new Cookie("USER", token);
    cookie.setHttpOnly(true);
    response.addCookie(cookie);
}

위와 같이 httpOnly 옵션을 켜주게 된다면 자바스크립트를 통해 쿠키를 조회하는 게 차단된다.

쿠키에는 하나의 쿠키당 4kb의 용량 제한이 있으며, 브라우저는 최소 300개 이상 허용될 수 있도록 구성되어야 한다.

쿠키의 경우 사용자가 따로 요청하지 않아도 브라우저가 request 시에 자동으로 Request Header 정보에 넘어서 서버에 전송되기 때문에 이전의 인증 과정보다 비교적 간단해진다.

또한, 쿠키에는 여러 종류가 있는데 이에 대해서 간단하게만 짚고 넘어가자.

 

💬 Session Cookie
메모리로 저장되며, 만료 시간이 있으며, 브라우저가 종료 시 제거되는 쿠키이다.

💬 Persistent Cookie
파일로 저장되며, Max-Age / Expires 헤더 정보를 통해 장기간 유지가 가능하며 브라우저 종료와 상관없이 사용 가능한 쿠키이다.

💬 Secure Cookie
HTTPS에서 사용하는 쿠키. (httpOnly 이기 때문에 XSS 안전 보장)

💬 Third Party Cookie
사용자가 방문한 도메인이 아닌, 다른 도메인의 웹사이트가 사용자의 하드 디스크에 저장하는 쿠키.
보통 광고 목적으로 사용될 때가 많다.

하지만, 앞서 말한 것처럼 쿠키에는 용량 제한이 있다.

이를 해결하기 위해 HTML5부터 추가된 저장소인 로컬 스토리지와 세션 스토리지를 사용할 수 있다.

 

 

📀 웹 스토리지

웹 스토리지에 저장된 데이터는 서버로 전송되지 않으며, window라는 객체 안에 들어있다.

브라우저, 기기별로 다르지만 모바일의 경우 2.5mb, 데스크탑은 5~10mb 정도의 용량을 가지고 있으며 사실 내부에 담는 정보의 크기는 매우 작기 때문에 쿠키에 비해 매우 넉넉하다고 할 수 있다. 이것도 부족하다면 50mb의 용량을 가진 IndexedDB를 활용하기도 한다.

 

또한, 도메인별로 용량 제한을 가지고 있기 때문에 CSRF로부터 안전하며, 프로토콜, 호스트, 포트 정보가 동일하다면 같은 스토리지를 공유하게 된다.

CSRF
: 인증된 사용자가 위조된 사이트에 접속하여, 위조된 사이트에서 위조된 요청을 접속했을 때 마치 인증된 사용자가 해당 요청을 수행한 것처럼 공격하는 방법. (사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹 사이트에 요청하는 공격)

 

대표적으로 로컬 스토리지와 세션 스토리지로 나눌 수 있는데, 로컬 스토리지의 경우 사용자가 데이터를 지우지 않는 이상 계속 브라우저에 남아있고, 세션 스토리지의 경우 윈도우나 브라우저의 탭을 닫을 경우 제거되는 방법이다.

요런 느낌 - 클라이언트 측에서 관리

 

하지만, 인증을 유지하기 위해 스토리지에 저장하게 되면 해커가 접근하기가 쉽다. 

우선 기본적으로 웹 스토리지 방식의 경우 서버가 아닌 클라이언트가 정보를 관리하고 있기 때문에, 비교적 보안에 취약하다.

스토리지에 있는 정보를 탈취하게 되면 결국 사용자의 정보가 그대로 노출되기 때문이다.

 

---

 

🌱 3. 안전하게 인증하기

좀 더 안전하게 인증하기 위해서, 쿠키 대신에 세션을 한 번 활용해보자.

세션은 인증된 사용자의 식별자와 랜덤한 문자열을 바탕으로 SessionID를 생성하여 response header를 통해 클라이언트에게 넘겨주는 것이다. 서버 측에 저장되기 때문에 비교적 안전하게 관리되며, 탈취를 당하더라도 session ID 정보만 담겨있기 때문에 앞서 클라이언트의 정보가 그대로 반환되었던 쿠키보다는 비교적 안전하다. (비교적! 안전하다는 것이 포인트)

또한, 세션의 경우 '만료 기한'을 정할 수 있기 때문에, 만료 기간이 지난 세션 정보의 경우 무의미해진다.

해당 세션이 탈취되었다고 서버에서 판단했을 경우 해당 세션 정보를 제거하면 되기 때문에 비교적 안전성이 높다.

 

 

💬 스프링은 세션을 어디에서 관리할까?

사실 개인적으로 찾아본 내용이어서 정확하지는 않다.

내가 알기에 세션은 톰캣의 세션 저장소에서 저장되는 것으로 알고 있었는데, 실제 내부 구조가 궁금해졌다.

// StandardSession.java
protected ConcurrentMap<String, Object> attributes = new ConcurrentHashMap<>();

public void setAttribute(String name, Object value, boolean notify) {
	...
    // Replace or add this attribute
    Object unbound = attributes.put(name, value);
}

요런 식으로 StandardSession 클래스를 통해 메모리상에서 concurrentMap을 통해 관리하고 있음을 알게 되었다.

 

하지만! 세션 방식 역시 문제가 있다.

만약 서비스의 스케일이 커져서 서버에 대한 로드 밸런서가 생기고, 다중 서버로 구성된다고 생각해보자.

만약 서버 A를 통해 세션을 통해 인증하게 된다면, 이후 요청은 계속 세션을 통해서 인증을 진행하게 될 것이다.

하지만, 다음 요청이 로드 밸런서에 의해서 서버 B에게 요청을 전달한다면?

서버 A는 해당 세션 정보가 존재하고 있는데, 서버 B에는 세션 정보가 없기 때문에 또 다시 요청을 받아야 하는 상황이 생긴다.

 

이를 위해서 모든 서버에서 접근할 수 있는 하나의 세션 저장소를 관리하는 방법이 있다.

하지만, 이 경우 클라이언트가 많아진다면 하나의 세션 저장소로 관리하는 것은 무리가 있을 것이며, 만약 해당 세션 저장소가 장애가 발생한다면 모든 요청을 받지 못해 더 큰 장애가 발생할 수도 있다.

 

 

💬 Sticky Session

https://smjeon.dev/web/sticky-session/

혹은, Sticky Session을 활용할 수도 있다.

이는 특정 세션의 요청을 처음 처리한 서버로만 저장하는 것으로, 하나의 세션 정보가 다른 세션에게 요청되지 않도록 방지하는 방법이다.

즉, 로드 밸런서가 처음 요청을 처리한 서버에게로 라우팅을 계속 진행하는 것이다.

이를 위해서 쿠키에다가 클라이언트에 대한 정보를 담는 식으로 만든다고 한다)

 

하지만, Sticky Session의 경우 로드 밸런서가 의도치 않게 동작할 경우 장애 트레이싱이 굉장히 어려워지며, 특정 서버에만 요청이 몰릴 수도 있기 때문에 해당 서버가 장애가 발생하면 처리하기가 어려워진다.

 

 

💬 Session Clustering

이를 해결하기 위해, 각 세션들을 하나로 묶어서 클러스터로 관리하는 방식이 'Session Clustering'이다.

이렇게 되면 하나의 세션에서 장애가 발생했을 때, 장애가 발생한 세션은 클러스터로 묶여있는 다른 세션으로 이동되어 관리되기 때문에 장애가 발생하더라도 비교적 복구하기가 쉽다. 

하지만, 새로운 서버가 추가된다면 기존에 존재하던 WAS에 새로운 서버 정보를 입력하여 클러스터링을 해줘야 하기 때문에 조금 복잡할 수도 있다는 점이 존재한다.

- 톰캣에서는 세션 정보 복제를 위해서 하나의 세션이 변경되었을 때 다른 모든 세션에게 복제되는 All-to-all Session Replication 방식과 Primary 서버와 Secondary Server만 전체를 복사하고 나머지는 JSessionID만을 복제하여 사용하는 Primiary-Secondary Session Replication이 있다고 한다. 

 

 

💬 Session Storage 구성하기

사실 위와 같은 문제 때문에 가장 처음에 말한 '세션 저장소' 라는 개념을 도입한 것이다. 

세션을 위한 또 다른 저장소를 사용한다는 게 큰 부담이 될 수도 있다.

또한, 인증 작업을 위한 처리와 인가 작업을 위한 처리의 경우 매번 저장소를 들렸다 와야 하기 때문에 성능이 최우선이 된다.

그래서 보통 Disk I/O 작업이 필요없는, 메모리에 저장하는 방식인 'In-memory DB'를 많이 사용한다.

물론 메모리에 의존적이기 때문에 프로세스가 종료되었다면 전부 삭제되겠지만, 애초에 HTTP는 stateless하기 때문에 요청에 대한 정보가 사라지더라도 크게 문제되지 않는다. (세션 정보를 평생 저장할 필요는 없으니까)

 

특히 그중에서도 Redis, Memcached를 많이 사용하는데 간단하게 둘을 비교하고 글을 마무리하겠다.

둘 다 key-value 쌍으로 데이터를 저장하며 NoSQL, in-memory-db로 분류된다. (속도도 매우 빠르다!)

 

💬 Redis
다양한 데이터 구조 (List, Set... etc)를 지원함 / master-slave 구조 (여러 개의 복제본 생성 가능) / 스냅샷 지원 (특정 시점의 데이터를 저장하여 장애 상황 발생 시 복구 가능) / 트랜잭션 지원 (ACID) / 하지만 싱글스레드!

💬 Memcached
데이터를 문자열로만 저장하며, 멀티스레드 아키텍처 지원

---

글이 생각보다 길어져서 다음 포스팅에서는 JWT, oauth 인증 방식에 대해서 다뤄보고자 한다!