로그인 인증방식

현재 모바일이나 웹 서비스에서 가장 많이 쓰이는 통신 방식은 HTTP통신이다.
http는 하이퍼 텍스트 전송 프로토콜의 약자로 서로 다른 시스템들 사이에서 통신을 주고 받게 하는 가장 기본적인 프로토콜이다.

HTTP통신은 서버와 클라이언트 사이에 데이터를 주고 받는 방식으로 응답 후 연결을 끊기게 되며 과거에 대한 정보를 담지 않는다.

서버에 요청을 보내는 작업은 http메시지를 보내는 것이다. http 메시지의 구조는 일반적으로 헤더와 바디 두가지로 구성되며, 공백은 헤더와 바디를 구분짓는 역할을 한다. 여기서 헤더에는 기본적으로 요청에 대한 정보들이 들어간다. 바디에는 서버로 보내야 할 데이터가 들어가게 된다.

인증은 http메시지의 헤더에 인증 수단을 넣어 요청을 보낸다.

로그인 인증 처리하는방식.

1.1. 세션.

http는 웹서버와 클라이언트가 지속적으로 연결을 유지한 상태가 아니라 요청(request)-응답(response)의 반복이다. 즉, 일회성이므로 이전 요청과 새로운 요청이 같은 사용자에서 이루어졌는지를 확인하는 방법이 필요하다.

이때 등장하는 개념이 쿠키와 세션

• 쿠키
  유저가 웹 사이트를 방문할 때 사용자의 브라우저에 심겨지는 작은 파일.
  key-value형색으로 로컬 브라우저에 저장된다. 서버는 이 쿠키의 정보를 읽어 HTTP요청에 대한 브라우저를 식별한다.
  그러나 쿠키는 로컬에 저장된다는 문제로 악의적 사용자가 쿠키를 변조하거나 탈취해 정상적이지 않은 쿠키로 서버에 요청을 보낼 수 있다.
  그로 인해 사용하는 개념이 세션.

• 세션
  브라우저가 웹 서버에 요청을 한 경우 서버 내에 해당 세션 정보를 파일이나 DB에 저장하고 클라이언트의 브라우저에 session-id라는 임의의 긴 문자열을 준다.
  이때 사용되는 쿠키는 클라이언트와 서버간 연결이 끊어진 경우 삭제되는 메모리 쿠키를 이용한다.

• Servlet
  자바를 사용하여 웹을 만들기 위해 필요한 기술. 클라이언트가 어떠한 요청을 하면 그에 대한 결과를 다시 전송해주어야 하는데 이러한 역할을 하는 자바 프로그램.
  //html을 사용하여 요청에 응답한다.

http 요청이 오면 servlet이라는 객체를 만들어서 스프링 프레임워크로 보낸다. session 메모리 객체에 세션키를 발급하고 http 요청이 올 때 servlet 객체에 session key를 저장할 수 있는 어떤 정보를 준다. session에 key value 형태로 저장을 한다. servlet에 데이터를 저장할 수 있다.

http가 일회성이므로 session키를 쿠키에 저장하여 내가 요청한 값임을 확인할 수 있다. 스프링에서는 request객체에서 getsession을 통해 원하는 객체를 쿠키가 사라질 때까지 가져올 수 있다.
쿠키는 캐시를 지운다거나 할 때 사라진다.

즉, 브라우저에 아이디, 패스워드를 입력하고 서버에서 확인하고 스프링 디비에서 맞는지 확인 후 session에 사용자 정보를 넣는다거나 하는 방식이다.

이 방법은 예전에 사용하던 방식이다. 왜냐하면 여러가지 문제점이 발생했기 때문이다.

1. 서버가 한대일 수 없다.
   L4(로드밸런스 : 클라이언트가 요청을 하고 여기에 붙어있는 서버 중에서 가장 놀고 있는 서버를 찾아 연결시켜준다.) 각 서버에 Servlet이 다 깔려있다. 그래서 로그인 시 내 정보가 1번서버에 있는데 2번 서버에는 정보가 없는 문제점이 발생한다.
   또한, 한번 로그인한 브라우저는 세션 정보를 가지고 있으나 다른 브라우저에서는 재로그인이 필요하다.
2. 대부분의 경우에는 메모리에 저장하는데, 로그인 중인 사용자가 늘어날 경우 서버의 RAM에 부하가 걸리게 된다. 이를 피하기 위해 데이터베이스에 저장을 하기도 하는데, 이러한 방식 역시 데이터베이스에 무리를 줄 수 있다.
3. 사용자가 늘어나게 되면 더 많은 트래픽을 처리하기 위해 여러 프로세스를 돌리거나 컴퓨터를 추가하는 등 서버를 확장해야 한다. 세션을 사용한다면 세션을 분산시키는 시스템을 설계해야 하지만 이러한 과정은 매우 어렵고 복잡하다.
4. CORS문제
   웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

그래서 나온것이 토큰방식!!

1.2. 토큰방식

토큰방식은 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 한다. 세션을 이용하지 않고 인증해주는 서버가 따로 있다. (EX.네이버 로그인 Oauth인증)

클라이언트는 인증서버에서 인증을 받으면 인증서버는 토큰을 주고, 토큰을 가지고 서비스 서버에 서비스를 요청할 수 있다. 그래서 토큰만 가지고 있으면 어디서든지 서비스서버에 접근이 가능하다.
//인증서버를 따로 만들수가 없기 떄문에 우리는 서비스 서버에서 그냥 토큰 관리까지 하도록 하자.!

• 토큰방식의 장점
  1. 토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless하며, 클라이언트와 서버의 연결고리가 없어 확장하기에 적합하다. 즉, 세션에서는 해당 사용자가 처음 로그인 했던 서버에만 요청을 받도록 설정해주어야 하지만 토큰을 사용하면 어떤 서버로 요청이 와도 상관이 없다.
  2. 클라이언트가 서버로 요청을 보낼 때 더 이상 쿠키를 전달하지 않으므로, 쿠키 사용에 의한 취약점이 사라진다. 하지만 토큰 환경의 취약점이 존재 할 수 있으므로 이에 대비해야 한다.
  3. cors문제를 해결할 수 있는데 토큰을 사용하면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사 진행 후 요청을 처리할 수 있다.

최근에는 Json 포맷을 이용하는 jwt를 주로 사용하는데 이해 대해서는 다음 포스팅에서 알아보자.

Reference

https://mangkyu.tistory.com/55
https://tansfil.tistory.com/58