---

웹 어플리케이션에서 로그인을 구현하는 방법은 크게 다음과 같이 분류할 수 있다.

• Cooke, Session을 이용하는 방법

• Token을 이용하는 방법

간단히 말하면 Cookie, Session 방식은 서버에서 Session ID를 기록한 뒤 브라우저에서 쿠키를 저장하는 방법이며, Token 방식은 토큰을 발행하여 토큰의 유효성을 검증하는 방법이다.

본 포스팅에서는 위에서 설명한 2가지 로그인 방법에 대해서 설명하고자 한다.

Cookie, Session

Cookie, Session방식은 기본적으로 Session 저장소를 기반으로 동작한다.

Session 저장소는 로그인시 사용자의 정보를 저장하고 열쇠로 사용할 수 있는 Session ID를 생성한다. 그리고 이를 HTTP Header에 포함하여 클라이언트로 전달한다.

이 후 브라우저에서 Session ID를 포함하는 Cookie를 저장하여 인증이 필요한 요청에 해당 쿠키를 포함하여 서버에 요청을 보낸다.

구체적인 인증 절차는 다음과 같다.

1. 클라이언트에서 서버로 자원을 요청하면 서버에서는 해당 클라이언트를 특정할 수 있는 데이터를 기반으로 세션 아이디를 생성
2. 해당 ID를 Key값으로 사용하여 필요한 값들을 서버 메모리에 저장한 뒤, 인증이 필요한 요청마다 Cookie를 Header에 포함하여 전달
3. 서버에서 Cookie를 받아 Session 저장소를 참조하여, 일치하는 정보를 가져온다.
4. 인증이 완료되고 서버는 사용자와 일치하는 데이터를 전달

만약 이 과정에서 Cors가 발생한다면 credentials 등의 세팅이 필요하다.

특징

Cookie와 Session의 차이점은 다음과 같다.

Cookie: 서버로부터 Session을 사용하기 위한 Key 값(Session ID)
Session: 서버에서 가지고있는 정보

Cookie만을 사용한 인증 방식은 서버 자원을 사용하지 않아 클라이언트가 인증 정보에 대한 책임을 지는것을 의미한다.

또한 해당 방식은 해커가 HTTP 요청을 중간에서 가로채 정보가 탈취될 수 있는 위험성이 존재한다.

따라서 인증의 책임을 서버가 담당하기 위해 주로 Session과 함께 사용한다.

즉, 사용자는 Cookie를 이용하고 서버에서는 Cookie를 받아 Session 정보에 접근하는 방식으로 인증을 진행한다.

장, 단점

Cookie, Session을 사용한 로그인 방식의 장점과 단점은 다음과 같다.

장점

• Cookie가 포함된 HTTP 요청이 노출되어도 중요한 정보는 서버 Session의 존재하기 때문에 안전하다.

• 고유 ID값을 발급받아 별도의 확인과정 필요없기 때문에 특정 서버 자원에 접근하기 용이하다.

단점

• Session 하이재킹 공격 가능성이 존재한다. 그래서 이를 방지하기 위해서는 HTTPS 를 사용하여 요청 안의 정보를 난독화하거나, Session에 특정 유효시간을 부여한다.

• Scale-out으로 서버의 성능을 늘릴 경우, 각 서버의 세션에 동기화 작업을 진행해야 되서 추가적인 비용이 발생 할 수 있다.

Scale-out, Scale-up

Scale-out과 Scale-up은 서버의 성능을 물리적으로 올리는 방법을 말한다.

Scale-out은 서버의 갯수를 늘려서 성능을 올리는 방법을 뜻하며, Scale-up은 서버 자체의 성능(디스크의 용량 등)을 올리는 방법이다.

따라서 Session 방식의 경우 서버 메모리에 의존적이기 때문에 서버의 갯수를 늘리는 Scale-out방식으로 성능을 올릴 경우 세션에 대한 데이터를 어떻게 공유시킬 건지에 대한 추가적인 고민이 필요하다.

---

Token (JSON Web Token)

Token 방식은 인증에 필요한 정보들을 암호화시킨 토큰을 의미하며, 앞서 설명한 Cookie, Session 방식과 유사하게 Access Token을 HTTP Header 포함하여 서버에 전송한다.

이 때 Token은 임의로 생성된 비밀번호와 같이 동작하며, 제한된 수명을 가지고 새로운 토큰은 한번 만료되면 새로 생성(Refresh Token)해야 한다.

구체적인 인증 절차는 다음과 같다.

1. 클라이언트에서 서버로 자원을 요청하면 서버에서는 계정 정보를 읽어 사용자를 확인하여 사용자의 고유 ID 값을 부여한 뒤 기타 정보와 함께 Payload에 포함
2. JWT 토큰의 유효기간을 설정한 뒤, 암호화할 Secret key를 이용하여 Access Token을 발급
3. 사용자는 Access Token을 전달 받아 저장한 뒤, 인증이 필요한 요청마다 Token을 Header에 포함하여 전달
4. 서버에서 해당 토큰의 Verify Signature를 Secret key로 복호화한 뒤, 조작 여부, 유효기간을 검증
5. 검증이 완료되면 Payload를 디코딩 하여 사용자의 ID 에 맞는 데이터를 전달

특징

Cooke, Session 방식과 Token 방식의 가장 큰 차이점은 Cooke, Session 방식은 Session 저장소에 유저 정보를 보관하지만, Token 방식은 토큰 안에 유저 정보들을 보관한다는 점이다.

즉, 클라이언트 입장에서는 HTTP Header에 Session ID, 또는 토큰을 포함하여 전달한다는 점에서는 동일하다.

하지만 서버 측에서는 인증을 위해 암호화를 하는 점과 별도의 저장소를 이용한다는 점이 차이점이다.

장, 단점

Token (JWT)을 사용한 로그인 방식의 장점과 단점은 다음과 같다.

장점

• 사용자의 인증을 토큰을 통해서 관리하기 때문에 서버의 Scale-out에서도 인증이 자유롭다.

• 사용자에 대한 인증 방식의 확장이 가능하다. (facebook, google...등의 소셜 로그인)

단점

• 사용자를 block을 시켜야 할 때 Session 방식은 세션 아이디를 파기하여 즉시 block할 수 있지만, Token 방식은 발급한 토큰이 만료되기 전까지 사용자에 대한 인증이 유효할 수 있다.

• Payload는 개별적으로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. 그래서 보안상의 이유로 민감한 정보들을 Payload에 포함할 수 없다.

---

참고 자료

Differences Between Cookies, Sessions and Tokens - Nomad Coders
Web, Cookie, Session, Token 인증 정의 및 특징 - IT blog