Delivery Together - JWT 인증방식의 로그인(1)

JWT의 사용 이유

HTTP 프로토콜의 문제점

REST API가 있고 권한이 있는 사용자에게만 액세스를 제한하려고 한다는 상황을 가정해 보겠다.

가장 단순한 접근 방식은 API가 사용자 이름과 비밀번호를 요청하는 것이다. 그리고 해당 정보가 실제로 존재하는지를 데이터베이스에서 검색해 인증을 확인한다. 마지막으로 인증된 사용자에게 해당 요청을 수행할 권한이 있는지 확인한다.

두 검사 모두 통과하면 실제 API가 실행되는 것이다.

 

 

하지만 문제점이 있다. HTTP 프로토콜은 Stateless로 동작한다. 위 그림과 같이 새 요청(GET/order/42)은 이전 요청에 대해 아무것도 알지 못하기 때문에 새 요청마다 다시 인증을 해야 하는 절차가 추가된다. 즉, 새로운 요청이 있을 때마다 리소스가 소모된다는 뜻이다.

 

 

이를 처리하는 전통적인 방법은 SSS(Server Side Sessions)를 사용하는 것이다. 이 시나리오를 통해 보자면, 먼저 사용자 이름과 비밀번호를 확인하다. 해당 정보가 인증된 경우, 서버는 Session ID를 메모리에 저장하고 그 ID를 클라이언트에게 반환한다. 그 후부터는 클라이언트를 식별하기 위해 Session ID를 서버로 보내면 된다.

 

하지만 이러한 해결 방법은 다른 문제를 만들게 된다.

 

확장에 대한 문제

API 시대에는 수많은 요청에 직면할 수 있으므로 인프라의 확장이 필요하다. 확장에는 두 가지 유형이 있다.

 

    1. 수직 확장 : 서버에 더 많은 리소스를 추가하는 것을 의미한다. 이는 매우 비싼 해결책이 될 것이다.

    2. 수평 확장 : 로드 밸런서 뒤에 새 서버를 추가하는 것을 의미한다. 이는 더 간단하고 비용면에서 효과적이다.

 

두 번째 접근이 유리하다는 것이 명확해 보인다. 아래 그림을 통해 어떤 일이 일어날지 한번 살펴보도록 하겠다.

 

 

초기에는 로드 밸런서 뒤에 서버가 하나만 있다. 클라이언트가 Session ID xyz를 사용하여 요청을 수행하면 해당 레코드는 서버의 메모리에서 찾을 수 있다는 것이 보장된다.

 

 

이제 위의 인프라를 확장해야 한다고 상상해 본다. 새로운 서버(Server 2:2)가 로드 밸런서 뒤에 추가되며, 추가된 새로운 서버는 클라이언트의 Session ID인 xyz를 인증하지 못하는 문제가 발생한다. 새로운 서버의 메모리에는 xyz 세션이 없기 때문에 인증 프로세스가 실패하는 것이다.

 

위와 같은 무제를 해결하기 위해 사용할 수 있는 세 가지 해결 방법이 존재한다.

 

    1. 서버 간 세션 동기화 : 구현이 까다롭고 오류가 발생하기 쉽다.

    2. 외부 인메모리 DB 사용 : 좋은 해결책이지만 다른 인프라 구성요소가 추가된다.

    3. 다른 세 번째 방법 : HTTP의 Stateless 특성을 수용하고 더 나은 해결책을 찾는다.

 

더 나은 해결책

JWT(Json Web Token)는 공개 표준(RFC 7519)으로, 발급자 및 대상 간에 인증 및 권한 부여와 같은 정보를 전송하는 방법을 정의한다. 발행된 각 토큰은 디지털 서명이 되어 안전한 통신이 이루어지므로 사용자는 토큰이 진짜인지 또는 위조되었는지를 확인할 수 있다.

각 토큰은 API에 대해 주어진 요청을 허용하거나 거부하는데 필요한 모든 정보가 포함되어 있다.

 

Web Study - JWT란?

위 링크를 통해 JWT가 무엇인지 알아볼 수 있다,

 

JWT 인증

 

처음 액세스 할 때 클라이언트는 권한 부여 서버에 연결하여 사용자 이름과 암호를 보내야 한다. 자격 증명이 유효하면 JWT가 클라이언트에 반환이 되고, 이를 사용하여 API를 요청할 수 있게 된다.

JWT에는 인증에 필요한 모든 정보를 포함하기 때문에 DB와 같은 서버와의 커뮤니케이션 오버 헤드를 최소화할 수 있다.

 

정리

1. HTTP 프로토콜은 Stateless 하므로 새 요청은 이전 요청에 대해 아무것도 알지 못한다.

2. SSS는 HTTP의 Statelss에 대한 해결책이었지만, 장기적으로 보았을 때 확장성에 위협이 된다.

3. JWT는 API에 대한 요청을 허가하거나 거부하는데 필요한 모든 정보가 자체 포함되어 있다.

4. JWT는 설계상 Stateless 하므로 HTTP의 Stateless와 싸우지 않아도 된다.

5. JWT는 암호화되어 있는 것이 아닌, 인코딩 되어있다.

---

GitHub - yu-capstone-design/delivery-together: 🍕 배달 주문을 같이할 사용자를 찾도록 매칭 서비스를 제공