why
->
예전에 혼자서 프로젝트를 할 때에는 서버를 따로 구성하지않고 서버의 역할을 FireBase가 수행하도록 했었다. 물론 인증작업도 전부 FireBase를 이용해서 처리했다.(굉장히 편했다!!!)
이번 프로젝트는 서버를 구성하고 진행하기 때문에 공부해할게 너무 많다. 특히 인증과 관련된 내용에 대해 거의 전무하다고 볼 수 있다. 그래서 여러 블로그와 구글링을 통해서 얻게된 인증과 관련된 배경지식을 이곳에 정리해둘 것이다.
글은 총 3개의 시리즈로 작성할 예정이다.(어쩌면 더 많아질 수 도있고...)
what
->
1. 인증이란?
현재 모바일에서 서버와 통신을 할 때 가장 많이 쓰이는 방식은 HTTP방식이다. 이 HTTP방식은 TCP프로토콜을 기반으로 작동이되고 처음에 서버와 연결이 잘되어있는지 확인하는 handShacking절차를 거친 후 통신을 하게된다.
HTTP방식은 서버에 요청을 하고 응답을 받게되면 연결이 끊기게되는데 이러한 과정에서 서버와 클라이언트는 HTTP메세지를 통해 통신을 하게된다.(http메세지는 서버와 클라이언트가 주고받는 편지라고 생각하는게 편할 거 같다.) 이 HTTP메세지에 대한 설명은 이전 글에 포스팅을 했기 때문에 여기서는 따로 설명하지 않겠다.
HTTP메세지에 대한 내용은 여기있다.
서비스를 이용하게 되면 사람마다 서버로부터 전송받는 데이터가 전부 다르기 때문에 서버는 사용자를 구분해야할 필요성이있다. 이때 사용되는 것이 인증이다.(그냥 보안이 필요없고 모든 사용자에게 동일한 정보를 제공한다면 굳이 필요하지않을 수도 있겠지만 과연 그게 가능할까????)
이러한 인증방식에는 여러가지가 있는데, 오늘은 회원정보를 HTTP헤더에 넣어서 보내는 방식과, Session/Cookie 방식에 대해서 정리할 예정이다.
2. 인증방식의 종류 및 설명
HTTP요청메세지 헤더의 계정정보를 넣어서 보내는 방식
사용자가 로그인을 하면 아이디와 비밀번호를 HTTP요청메세지 헤더에 담아서 서버로 보내고 서버는 해당 정보와 일치하면 로그인이 완료되었다고 처리해주는 방식이다. 이 방식은 중간에 해커가 HTTP요청메세지를 가로챈 후 사용자계정의 로그인하여 원하는 정보를 마음대로 가져갈 수 있기 때문에 보안적으로 굉장히 취약하다. 절대 절대 실제 서비스에서 사용하면 안된다.!!!!!
Session / Cookie 방식
Cookie
- 웹 서버가 브라우저에게 지시하여 사용자의 로컬 컴퓨터에 파일 또는 메모리에 저장하는 작은 기록 정보 파일입니다.
- 파일에 담긴 정보는 인터넷 사용자가 같은 웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀔 수 있습니다.
Session
HTTP Session id를 키값으로 사용하여 서버 DB에 저장된 정보를 이야기한다.
클라이언트는 HTTP Session id를 쿠키로 메모리 저장된 형태로 가지고 있습니다.
Session과 Cookie를 활용한 방식의 절차는 아래와 같다.(너무 간단하게 설명해주는 블로그가 있어 거기서 절차와 관련된 내용을 가져왔다.)
<출처 : https://tansfil.tistory.com/58>
- 사용자가 로그인을 한다.
- 서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 세션ID를 발행합니다.
3 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냅니다. - 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옵니다.
- 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줍니다.
- 세션 쿠키 방식의 인증은 기본적으로 세션 저장소를 필요로 한다.
- 세션 저장소는 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션ID값을 만듭니다. 그리고 HTTP 헤더에 실어 사용자에게 쿠키 형태로 돌려보낸다. 그러면 사용자는 쿠키로 보관하고 있다 인증이 필요한 요청에 쿠키(세션ID)를 넣어서 서버로 보내게된다.
- 서버는 쿠키를 세션 저장소로 보내서 일치하는 정보가 있는지 확인 후 일치한다면 클라이언트에게 요청한 데이터를 보내주게된다.
- 세션ID = 쿠키라고 생각해도된다.
장점:
1. 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠라고 보면된다. 그래서 해커가 이 쿠키값을 가로채는 것은 계정정보 자체를 가로채는 것 보다는 안전한다(근데 솔직히 이것도 그리 좋은 방법은 아닌것 같아! 만약 쿠키를 이용해서 세션 저장소에 접근하여 인증 받고 DB에 접근하면 끝인거 아닌감? 그래서 이에대한 해결책을 아래 단점부분에서 설명할 것!! )
- 사용자 A는 1번, 사용자 B는 2번 이런식으로 고유의 ID값을 발급받게 됩니다. 그렇게 되면 서버에서는 쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지를 확인할 수 있어 서버의 자원에 접근하기 용이할 것입니다.
단점:
1. 위에서 쿠키를 탈취당하더라도 안전할 수 있다고 언급했고 해당 장점에 대해 의구심을 품었다. 왜냐면 해커가 탈취한 쿠키를 이용해서 DB에 접근 후 개인정보를 충분히 가져올 수 있기 때문이다.
해결방법!
- HTTPS를 사용해 요청 자체를 탈취해도 쿠키를 읽을 수 없게 암호화처리를 한다.
- 세션에 유효시간을 넣어준다.
- 서버에서 세션 저장소를 사용한다고 했습니다. 따라서 서버에서 추가적인 저장공간을 필요로 하게되고 관리하기 더 힘들어질 것이다.
참고
https://tansfil.tistory.com/58
https://nesoy.github.io/articles/2017-03/Session-Cookie
