쿠키/세션 인증, 토큰 인증

인증이 필요한 이유

• 프론트 관점: 사용자의 도입부분(로그인, 회원가입)
• 서버 관점: 모든 API요청에 대해 사용자를 확인하는 작업

같은 어플리케이션이라도 사람마다 사용하는 컨텐츠가 다르다. 서버는 사람들이 요청하는 정보를 정확히 '구별'해서 전달할 수 있어야 한다.

그렇지 않으면, 요청한 정보를 못보거나 더 안좋은 경우로는 다른 사람의 중요한 정보를 보내게되는 경우가 생길 수 있다.

따라서 프론트엔드는 현재 정보를 요청하는 자가 누구인지 알수있도록 단서와 함꼐 서버에 요청을 한다. 서버는 그 단서를 보고 어떤 정보를 보내줄지 결정을 한다.

인증방식

1. 계정정보를 요청 헤더에 삽입

• 장점
  -인증 테스트를 빠르게 할 수 있다.
• 단점
  -보안에 매우 취약하다
  -서버에서 신호가 올때마다 id/pw를 통해 유저가 맞는지 인증해야 한다.(비효율)

2. Session/Cookie 방식

계정정보를 요청헤더에 넣는 방식의 대안으로 등장했다.

1. 로그인을 한다
2. 서버에서 계정정보를 읽어 사용자를 확인한다.
3. 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장하고,이와 연결되는 세션 ID를 발행한다.
4. 사용자는 해상 세션 ID를 받아 쿠키에 저장하고, 인증이 필요할때마다 쿠키를 헤더에 실어 보낸다.
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.

• 장점
  -세션/쿠키 방식은 쿠키를 매개로 인증을 거친다. 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠이다. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라고 쿠키 자체는 유의미한 값을 가지지 않는다(암호화 되어있다). 중요한 정보는 세션에 있기때문에, 실제 계정정보를 헤더에 넘기는 방식보다는 안전하다

  -사용자들은 고유의 ID를 발급받는다. 그러면 서버에서는 쿠키값을 받ㅇ았을 때 일일이 회원정보를 확인할 필요가 없고, 바로 어떤 회원인지 확인할 수 있다. 이는 서버 자원에 접근하기 용이한 방법이다.
  

• 단점
  - 사용자의 HTTP요청이 해커가 가로챈다면, 그 안에 있는 쿠키를 훔칠 수 있. 그러면 해커는 훔친 쿠키를 이용해 HTTP요청을 보내고, 서버의 세션저장소에서 사용자의 정보를 얻을 수 있다. -> HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 얻을 수 없게 한다. 세션에 유효시간을 넣어준다(만료되면 사라지도록).

  -세션저장소를 사용할 별도 공간이 필요하다. 자연스럽게 서버 부하가 높아진다.

3.토큰 기반 인증 방식

세션/쿠키처럼 암호화된 토큰을 HTTP 헤더에 넣어 서버로 정보를 요청한다. 토큰을 만들기 위해서는 3가지가 필요하다. 바로 header, payload, signature이다. header는 정보를 암호화한 방식, 타입이 들어간다. payload는 실제 정보가 들어간다. 일반적으로 유저의 고유 ID, 유효기간이 들어간다. signature는 header,payload + secret값으로 구성된다.

JWT 방식은 다음과 같이 이루어진다.

1. 사용자가 로그인을 한다
2. 서버에서는 계정정보를 읽어 사용자를 확인한다
3. 사용자의 고유한 ID값을 부여한 후, 기타정보와 함께 payload에 넣는다.
4. JWT 유효기간을 설정한다
5. 암호화할 SECRECT_KEY를 이용해 ACCESS_TOKEN을 발급한다
6. 사용자는 토큰을 받아 저장 후, 인증이 필요할 때마다 토큰을 헤더에 실어 보낸다
7. 서버ㅔ서는 해당 토큰의 signature를 SECRECT_KEY로 복호화한 후 조작 여부, 유효기간을 확인한다
8. 검증이 완료되면 payload를 디코딩해 사용자에 맞는 데이터를 가져온다.

JWT는 토큰 안에 유저 정보를 넣는다는 것이 쿠키/세션과 큰 차이점이다(쿠키/세션은 서버의 세션 저장소에 저장).

• 장점
  -간편하다.
  -발급 후 검증만 하면 되기에 추가 저장소가 필요하지 않다. 이는 statelessg한 서버를 만드는 입장에서 큰 강점이다. 이는 서버 유지/보수에 유리하다.
  -확장성이 뛰어나다. 토큰 기반 인증은 다른 시스템에 접근이 가능하다.
• 단점
  - 이미 발급된 JWT는 돌이킬 수 없다. JWT는 한번 발급되면 유효기간이 완료될 떄가지 계속 사용이 가능하다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 '특정정보'에 접근이 가능하다. (기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급하면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있다.)
  -payload 정보가 제한적이다. payload는 따로 엄호화되지 않기에 쉽게 정보 확인이 가능하다.
  -JWT의 길이. 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생한다.

출처

쉽게 알아보는 서버 인증 1편(세션/쿠키, JWT)