Token 기반 인증

Cookie와 Session에 대해서는 Session과 Cookie 를 참고할 것.

1. 전통적인 인증 방식

전통적인 인증 방식은 쿠키와 세션을 사용한다.

1.1. 서버 기반 인증의 문제점

A. 세션

사용자가 로그인을 할때 서버는 SessionID를 생성하는데 이 값을 계속 관리해야 하는 문제가 있다.

B. 확장성

세션을 사용하면 서버 분산 확장이 복잡해진다.
서로 다른서버에서 세션에 대해서 인증을 할 수 있어야 하기 때문이다.

C. CORS(Cross-Origin Resource Sharing)

세션을 관리할때 주로 쿠키를 사용한다.
쿠키는 단일 도메인 및 서브도메인에서만 작동하도록 되어 있다. 이 때문에 쿠키를 여러 도메인에서 사관리하는 것이 번거롭다.

D. 모바일 환경에 적합하지 않다.

기존에 HTTP 통신의 Client는 브라우저가 거의 유일했으나 현재는 다양한 모바일 환경이 있다.
이런 환경에서 인증을 위한 쿠키, 세션을 다루는 방법은 구현의 복잡도를 야기한다.

2. Token 기반 인증 방식

세션을 발급하는 것이 아니라 Token을 발급한다.

1. 클라이언트는 ID/PW를 전송하여 서버에 인증을 요청한다.
2. 서버는 계정정보를 검증하고 유효한 경우 signed Token을 발급한다.
   (signed Token이란 정상적으로 발급된 토큰임을 인증하는 signature를 가지고 있다는 뜻이다.)
3. 클라이언트는 Token을 가지고 있으면서 추후 서버 요청 시 Token을 함께 전달한다.
4. 서버는 Token을 검증하고 요청에 응답한다.

Token에는 사용자 식별 정보가 포함되어 있다. 따라서 서버는 토큰을 통해 어떤 사용자인지 식별할 수 있다.

2.1. Token 기반 인증의 장점

A. stateless 하다.

토큰은 서버에서 별도로 관리하지 않는다. 따라서 세션을 사용함으로써 발생하는 서버 확장의 문제가 없다.

B. Client에 독립적이고 여러 도메인에서 사용할 수 있다.

토큰은 세션처럼 쿠키를 통해 전달하는게 아니라 Request Header를 통해 전달된다. 따라서 HTTP request를 만들 수 있다면 누구든 요청을 보낼 수 있다.
또한 쿠키를 사용하지 않아 CORS 문제가 없다.

C. 보안

쿠키를 사용하지 않아 이로 인해 발생하는 취약점이 사라진다.

D. 확장성

Token 기반 인증은 단순 내 서버에 인증하는 역할 뿐 아니라 인증의 사용 범위를 확장시킬 수 있다.
대표적인게 oAuth 이다.

2.2. JWT

JSON Web Token으로 Token 규격에 대한 표준 format 이다.

---

[참고 문서]

1. 참고 블로그
2. 참고 블로그
3. 참고 블로그
4. JWT 관련
5. JWT 관련