현대화가 진행이 될 수록, 인터넷이 빨라질수록, 기술이 발전할수록 우리들의 삶은 인터넷과 밀접한 관계가 형성이 되고 회사 업무, 은행 업무, 가사 등등 인터넷에 의존하는 일이 많아지고 있다.
자연스레 인터넷에 로그인과 같은 개인정보를 제공해야하는 과정이 필수가 되어지고 있으며, 보안 및 개인 인증 절차도 자연스레 필수 요소가 되어지고 있다.

오늘은 포스팅에서는 인증절차에 관한 내용을 적어보고자 한다.

What I Learned Today :)

  💻  Session
  🍪  Cookie
  💳  Token

세션 / 쿠키 인증

우리는 자주 방문하는 웹 사이트에서 한 번 로그인하고 일정시간 내에 재 접속을 하면 로그인을 하지 않아도 되는 경험을 종종 했다. 개인정보를 인증받고 그에 대한 정보들이 저장되어 있어서 그런데 모두 아래 등장하는 녀석들 덕분이다.

💻   Session

• 서버가 Client에 대해 유일한 ID를 부여하여 서버 측에서 관리 : Session ID
• 이 ID가 서버에서 존재하는 상황을 Session이라고 함
• 사용자의 정보 중 보안상 중요한 데이터는 Session에서 관리함

클라이언트와 서버 간의 관계를 유지하기 위한 방법으로,
서버와 클라이언트의 연결이 활성화 된 상태를 말하며 방문자가 서버에 접속하게 되면 방문자의 요구에 따른 정보를 저장하는 것을 말한다. 여기서 활성화 되었다는 말은 클라이언트와 서버가 서로 연결이 되어있을 때를 말한다. 이렇게 연결이 된 상태에서 저장된 정보들이 다음 접속할 때도 유지되는 것이 포인트다.

tip) 서버상에서 정보가 관리되는 경우를 세션이라고 하고, 브라우저의 메모리에서 관리하는 정보를 쿠키라고 한다.

🍪  Cookie

• 사용자 정보를 사용자 메모리(브라우저)에서 관리
• 서버가 사용자의 위치에 정보를 저장하고 불러올 수 있는 수단
• 클라이언트와 서버간 주고받는 편지.
• 구성
  - 이름
  - 값
  - 만료날짜
  - 경로 정보

그림상 마지막에 위치하고 있는 사용자의 request는 그 위의 response에서 받은 쿠키를 자동적으로 넣어 요청을 하고 있다. 이런 쿠키는 사용자 즉 Client에서 관리가 된다. 따라서 크롬 등 웹브라우저 설정에서 쿠키를 지울 수 있는 것이다.

  또한 브라우저가 서버와 연결이 되어있을 때 서버측에서 쿠키가 존재하지 않을 경우 자동으로 쿠키를 생성하며, 요청에 대한 데이터를 Response할 때 그 쿠키와 같이 보낸다. 그리고 그 이후 Client가 서버에 특정 요청을 보낼 때마다, 따로 액션을 취하지 않아도 자동으로 그 쿠키 정보가 http 요청에 담겨 전송이 된다.

💻🍪  세션 / 쿠키 인증 과정

그림 출처: 이호연님 블로그

1. 사용자 로그인 (request)
2. 서버에서 사용자의 정보를 확인
3. 사용자의 정보를 세션 저장소에 보관
4. 고유의 세션ID를 생성 및 발급
5. 세션 ID를 담은 '쿠키'라는 편지에 담아 사용자 로그인에 대한 response(응답)보내기
       - 인증이 필요할 때마다 쿠키를 헤더에 담아 요청
6. 사용자 재접속 및 로그인(request + 쿠키): 위에서 받은 쿠키 편지지를 들고 옴(통행권: "나 또 왔어 나 알지?")
7. 사용자가 준 쿠키를 세션 저장소에서 대조, 검증
8. 사용자의 요청을 담은 response
       - 주소를 직접 치고 들어가는 GET요청시 (서버 접속) 재로그인 할 필요 없을 때의 예제

토큰

💳  토큰

특정 정보들을 해싱해서 Client와 Server를 왕복한다는 것이 Token이다.
(해싱: 알고리즘과 암호 방식을 결합하면 다양한 방식으로 보안과 인증이 가능)

즉, Token이란! 인증을 위해 사용되는 암호화 된 문자열이다.

• HTTP 통신의 Stateless 특징과 알맞다. (요것은 Session / Cookie도 마찬가지)
  - 서버와 클라이언트는 통신이 끝나면 상태정보를 유지하지 않는 특성이 있는데(정확히 말하면 http 통신이 stateless이기 때문) 이것을 stateless라고 한다. 즉 쿠키에 토큰을 담아 상태관계를 유지한다.
  - Client가 토큰을 지니고 있으면 그 정보만을 가지고 위의 연결 상태에 연연하지 않으며, Server는 "요놈이 맞구나!"라면서 Server에서 api를 설계할 수 있다.
• 유저의 인증 정보를 server 혹은 session에 담아두지 않음
• 유저의 활성화 여부를 신경쓰지 않고 넘겨진 요청에 담겨진 Token의 정합성만 확인
  - 특정 요청에 대해만 이 Token이 변형된건지 혹은 정상적인 것인지 확인 후 진행
• 서버에서 Client의 상태 정보를 저장(세션 저장소)하지 않고, Client로부터 전달받은 요청만으로 작업을 처리하는데, 이 경우 Client의 상태 관리에 대한 비용이 없기 때문에 Server의 확장성이 높음
  - 만약 Session으로 관리를 했을 때, "아, 요놈이 로그인 요청을 했고, 어디까지 들어와서 어떤 요청을 했다"라는 것들을 가공하는 부분에서도 코드를 짜야하는 비효율성 증대
  - 하지만, Token을 사용한다면 그냥 token의 정합성만 따지고 사용자에 관한 session 관리 코드를 짤 필요가 없다. 그저 Token 확인 후 요청한 걸 db에서 반환해주면 된다 (Express 사용시 토큰 체킹하는 미들웨어만 앞에 넣어주면 끝)
  
  

근데, 세션 토큰자체 정보만 인증하면 보안자체가 취약할 수도 있는데,

그럼 요청할 때마다 세션정보를 새롭게 한다던가
이 세션에 대해서 얘는 30분 동안만 사용할 수 있게 한다는 등등 세션을 유지하는 방법을 고안해야 한다고 한다.

다음 관련 포스팅 : Hasing & Salt

---

[참고]
https://tansfil.tistory.com/58