1. 세션, 쿠키가 필요한 이유
우리가 통신에서 가장 많이 쓰고 있는 http 방식은 stateless 속성을 갖는다. 이것은 클라이언트와 서버가 한번의 요청-응답 과정을 거친 후 연결을 끊게되며, 이전 통신에 대한 정보를 전혀 갖지 않게된다. 다시 말해, 다음 번의 통신때는 이전 통신에 의한 정보가 없다는 것이다.
클라이언트(유저)가 서버에 요청을 보낼 때, Header 부분에 유저에 대한 정보를 포함시키고, Body부분에 요청내용을 포함시켜서 보낸다. 특정 유저의 정보를 전달해주기 위해서 서버는 유저를 구분해야된다. 그렇기 때문에 인증(Auth)이 필요한 것이다.
Header에 유저의 ID와 PW를 담아서 보내면 인증이 되겠지만, 이렇게 하면 보안에 매우 취약하게 된다. 또한 서버에서 매 신호마다 유저를 인증해야해서 비효율적이다. 이에 따라 한번만 인증해도 특정 조건 및 기간 안에는 유저가 인증과정을 따로 거치지 않도록 하는 것이 세션과 쿠키이다.
2. 세션과 쿠키
번거롭고 비효율적인 사용자 인증 반복과정을 없애기 위해 나온 개념이 세션과 쿠키이다. 일정시간 동안 동일한 사용자에 대한 상태정보를 유지시키는 목적으로 사용한다.
- 각 사용자마다 고유의 세션 ID를 발급 받으므로, 서버에서는 세션 ID만 보면 어떤 사용자인지 알 수 있다. 따라서 보안에 취약하고, 서버에서 각 세션을 저장하기 위해서 저장공간이 필요하다.
>> HTTPS 사용, 세션에 유효시간 넣는 방법 등을 통해 보안을 보완할 수 있다.
- CORS시 번거로움
쿠키는 단일 도메인 및 서브 도메인에서만 작동되도록 설계되어서 여러 도메인에서 관리하기가 번거롭다.
3. 토큰
특징
인증을 위해 사용되는 암호화된 문자열이다. 유저의 정보를 기반으로 SHA-256 같은 암호화 알고리즘을 사용하여 해싱된 문자열을 token에 담는다. 세션-쿠키와 마찬가지로 사용자가 저장하고 있는 인증정보라고 할 수 있다. 보안문제에 관해서는 다음 'JWT 인증 방식' 절에서 살펴보도록 하자.
세션과 달리 유저의 인증 정보를 서버나 세션에 담아두지 않는다. 그러므로 세션처럼 stateful 서버 개념이 아닌 원래의 stateless 서버 개념으로 통한다고 생각할 수 있다.
토큰만 맞다는 정합성을 확인하며, 이에 따라 클라이언트에 대한 상태관리를 하지 않기 때문에 서버의 확장성이 크다.
>> 클라이언트와 서버의 연결고리가 없기 때문에, 서버의 확장성이 높아진다는 것이다. 대표적인 예로 OAuth를 이용하면 SNS 계정 들을 이용하여 다른 웹서비스에서도 이용할 수 있다. 또한 모바일 환경에 유리해진다. 세션을 기반으로 하면 모바일 환경에서 쿠키 매니저를 따로 관리해야하지만, 토큰 사용 시 웹 요청 API의 헤더 부분에 JWT가 담겨지므로, 관리가 용이하다.
단점
stateless 하기 때문에 토큰을 강제로 만료시킬 수 없다. 즉 사용자는 서버로부터 한 번 받은 토큰을 만료되기 전까지 계속해서 사용한다.
>> 만료 주기를 너무 짧게하면 사용자가 로그인을 해야하는 주기가 짧아지므로 불편해지고, 만료 주기를 길게 하면 토큰이 탈취되고, 피해가 커질 확률이 증가하게 된다.
한 번 발급되면 세션처럼 강제로 지울 수 없기 때문에, 유효기간이 지나기전에 Token을 탈취당하면(secret key까지) 심각한 정보 유출이 일어날 수 있다. 따라서 기본적으로 발급되는 Access Token의 유효기간은 짧게 하고, Refresh Token 이라는 새로운 토큰을 발급한다.
JWT 인증 및 작동 방식
jwt 사이트에 들어가보면 어떤 방식으로 JWT가 만들어지는지 그 형식을 알 수 있다.
Header 부분에 암호화 알고리즘(alg), 타입(typ)가 들어간다. Payload 부분에는 서버에 보낼 유저의 정보가 들어간다.
Verify Signature 부분에는 header와 payload를 인코딩한 내용에 유저의 Secret key를 더한 부분이 들어가게 된다.
작동방식
로그인 시에 사용자에 대한 검증을 사용자 DB에서 진행하고, JWT Access Token을 발행한다. 이때 중요한 것은, 처음 JWT 토큰을 받을 때는 secret key와 암호화된 Verify signature가 함께 서버로 전달되고, 서버에서 JWT 토큰을 발행할 때는 secret key를 제외한(암호화된 secret key의 문자열만 포함된) JWT를 사용자에게 전달한다는 것이다. 이렇게 되면 B 사용자가 A 사용자의 토큰을 탈취했더라도, 서버에 요청을 보내는 순간 B 사용자는 자동적으로 본인의 verify signature를 포함해서 A 사용자의 정보를 보내게 된다. 서버에서는 A사용자의 정보(payload)와 B 사용자의 verify signature를 함께 받은 것이 되기 때문에 올바르지 않은 신호로 여기고 인증을 거부할 수 있는 것이다.
다시 말해서, 접속하는 사용자는 각자의 secret key를 부여하고 토큰에는 이 정보가 암호화되어 담긴다. 서버에서는 payload와 secret key를 복호한 값의 일치성을 살피기 때문에, 해당 사용자의 secret key와 payload 정보가 다르다면 인증을 거부할 수 있다.
Access Token & Refresh Token
보안 강화를 위해서 기본적으로 발급되는 Access Token에 Refresh Token을 더하는 개념이다. 예를 들어 사용자에게 처음 발급 시에 Access Token과 이에 상응하는 Refresh Token을 함께 발행한다. Access Token의 사용 기한이 1시간이고, Refresh Token의 사용기한이 2주라면, Access Token의 사용기한 만료 시마다 사용자 측에서 Access Token의 재발급을 서버에 요청하게 된다. 서버에서는 사용자의 만료된 Access Token과 Refresh Token을 전달받아 정합성을 확인한 후 새로운 Access Token을 발급하게 된다.
참조
1) 이호연 블로그 : 쉽게 알아보는 서버 인증 1편(세션/쿠키, JWT)
https://tansfil.tistory.com/58
2) 영차영차 배토리의 개발블로그 : [Server] 세션, 쿠키, 토큰(JWT)
https://dunkey2615.tistory.com/119
3) dooo.park : 서버 기반 인증, 토큰 기반 인증(Session, Cookie / JSON Web Token)
https://dooopark.tistory.com/6
'Computer Science > Security & Auth' 카테고리의 다른 글
| Auth / Authentication vs Authorization(인증과 인가의 차이) (0) | 2020.10.30 |
|---|---|
| Web Arch. / Browser Security : CORS, XSS, CSRF (0) | 2020.10.05 |
