API를 사용하는 웹서비스를 개발한다면, 토큰을 사용하여 유저의 인증작업을 처리하는 것이 가장 좋은 방법이다.
📌토큰 기반 인증 시스템을 선택하는 이유는 다음과 같다.
1. Stateless 서버
Stateless 서버를 이해하기 위해서는 Stateful 서버를 알아야 한다.
● Stateful 서버
- Stateful 서버는 클라이언트에게서 요청을 받을 때마다, 클라이언트의 상태를 계속해서 유지하고, 이 정보를 서비스 제공에 이용한다.
- Stateful 서버 중 하나로 세션을 유지하는 웹서버가 있다. 예를 들어 유저가 로그인을 하면, 세션에 로그인이 되었다고 저장을 해 두고, 서비스를 제공할 때 그 데이터를 사용한다. 여기서 이 세션은 서버컴퓨터의 메모리에 담을 때도 있고 데이터베이스 시스템에 담을 때도 있다.
● Stateless 서버
- Stateless 서버는 반대로, 상태를 유지하지 않는다. 상태정보를 저장하지 않고, 서버는 클라이언트 측에서 들어오는 요청만으로만 작업을 처리한다.
- 이렇게 상태가 없는 경우 클라이언트와 서버의 연결고리가 없기 때문에 서버의 확장성(Scalability)이 높아진다.
2. 모바일 어플리케이션에 적합하다.
- Android/IOS 모바일 어플리케이션을 개발 한다면, 안전한 API를 만들기 위해서는 쿠키같은 인증시스템은 이상적이지 않다. (쿠키 컨테이너를 사용해야 한다.) 토큰 기반 인증을 도입하면 해결할 수 있다.
3. 인증정보를 다른 어플리케이션으로 전달할 수 있다.
- 대표적인 예로 OAuth가 있다. 페이스북/구글 같은 소셜 계정들을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
4. 보안
토큰 기반 인증 시스템을 사용하면 어플리케이션의 보안을 높일 수 있다.
📌토큰 기반 인증 시스템을 사용하는 서비스들
깃허브, 페이스북, 트위터 등 많은 서비스에서 사용하고 있다.
📌왜 토큰을 사용하게 되었을까?
토큰 기반 인증 시스템의 필요성을 알아보기 전에 먼저 과거의 인증시스템이 어떤 방식으로 작동했는지 살펴본다.
서버 기반 인증
기존의 인증 시스템에서는 서버측에서 유저들의 정보를 기억하고 있어야 한다. 이 세션을 유지하기 위해서 메모리/디스크/데이터베이스 시스템에 저장해서 사용했다.
이런 방식의 인증 시스템은 아직도 많이 사용되고 있지만 최근 웹/모바일 웹 어플리케이션들이 많이 사용되면서 이런 방식의 인증시스템은 문제가 생기기 시작했다. 예를 들어 서버를 확장하기가 어렵다는 단점이 있다.
서버 기반 인증의 문제점
1. 세션
유저가 인증을 할 때, 서버는 이 기록을 서버에 저장해야 하고 이를 세션이라고 부른다. 대부분의 경우에는 메모리에 이를 저장하는데, 로그인 중인 유저의 수가 늘어난다면 서버의 램이 과부화될 수 있다. 이를 피하기 위해서 세션을 데이터베이스 시스템에 저장하는 방식도 있지만 이것도 유저의 수가 많으면 데이터베이스의 성능에 무리를 줄 수 있다.
2. 확장성
세션을 사용하면 서버를 확장하는 것이 어렵다.
여기서 서버의 확장이란, 단순히 서버의 사양을 업그레이드 하는 것이 아니라, 더 많은 트래픽을 감당하기 위하여 여러개의 프로세스를 돌리거나, 여러 대의 서버 컴퓨터를 추가하는 것을 의미한다.
세션을 사용하면서 분산된 시스템을 설계하는 것은 불가능하진 않지만 과정이 매우 복잡해진다.
3. CORS(Cross-Origin Resource Sharing)
- CORS란 웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조이다.
- 웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.
📌 토큰 기반 시스템의 작동 원리
토큰 기반 시스템은 stateless 하다. 즉 상태유지를 하지 않는다. 토큰 기반 시스템에서는 유저의 인증 정보를 서버나 세션에 담아두지 않는다. 이렇게 되면 유저의 인증 정보를 서버 측에 담아둠으로서 발생하는 많은 문제점들이 해소된다.
세션이 존재하지 않으므로 유저들이 로그인 되어 있는지 안되어 있는지 신경 쓰지 않으면서 서버를 손쉽게 확장할 수 있다.
토큰 기반 시스템의 구현 방식은 다음과 같다.
1) 유저가 아이디와 비밀번호로 로그인을 한다.
2) 서버 측에서 해당 계정정보를 검증한다.
3) 계정정보가 정확하다면, 서버측에서 유저에게 signed 토큰을 발급해준다.
- 여기서 signed의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature를 지니고 있다는 것이다.
4) 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 함께 서버에 전달한다.
5) 서버는 토큰을 검증하고, 요청에 응답한다.
웹서버에서 토큰을 서버에 전달 할 때에는, HTTP 요청의 헤더에 토큰값을 포함시켜서 전달한다.
📌 토큰의 장점
1. stateless이며 확장성(scalability)이 있다.
토큰을 클라이언트 측에 저장하기 때문에 완전히 stateless하며, 서버를 확장하기에 매우 적합한 환경을 제공한다.
만약에 세션을 서버측에 저장하고 있고, 서버 여러대를 사용하여 요청을 분산했다면, 어떤 유저가 로그인 했을 때, 그 유저는 처음 로그인했었던 서버에만 요청을 보내도록 설정해야 한다.
하지만 토큰을 사용한다면, 어떤 서버로 요청이 들어가던 상관이 없게 된다.
2. 보안성
클라이언트가 서버에 요청을 보낼 때 더 이상 쿠키를 전달하지 않기때문에 쿠키를 사용함으로 인해 발생하는 취약점이 사라진다. 물론 토큰을 사용하는 환경에서도 취약점이 존재할 수 있으므로 대비해야 한다.
3. Extensibility(확장성)
여기서 확장성은, Scalability와는 또 다른 개념이다. Scalability는 서버를 확장하는 것을 의미하는 반면, Extensibility는 로그인 정보가 사용되는 분야를 확장하는 것을 의미한다. 토큰을 사용하여 다른 서비스에도 권한을 공유할 수 있다. (소셜플랫폼 연동 로그인 가능)
그리고 토큰 기반 시스템에서는, 토큰에 선택적인 권한만 부여하여 발급할 수 있다. 예를 들어 소셜플랫폼 연동 로그인을 할 때 프로필 정보를 가져오는 권한은 있어도, 포스트를 작성할 수 있는 권한은 없다.
4. 여러 플랫폼 및 도메인
서버 기반 인증 시스템의 문제점을 다룰 때 CORS에 대하여 언급했엇다. 어플리케이션과 서비스의 규모가 커지면, 여러 디바이스를 호환 시키고, 더 많은 종류의 서비스를 제공하게 된다. 토큰을 사용한다면, 그 어떤 디바이스에서도 어떤 도메인에서도 토큰만 유효하면 요청이 정상적으로 처리된다. 서버측에서 어플리케이션의 응답부분에 다음 헤더만 포함시켜주면 된다.
Access-Control-Allow-Origin: *
이런 구조라면, assets 파일들(이미지, css, js, html 파일 등)은 모두 CDN에서 제공을 하도록 하고, 서버측에서는 오직 API만 다루도록 설계할 수 있다.
5. 웹 표준 기반
토큰 기반 인증 시스템의 구현체인 JWT는 웹 표준 RFC 7519 에 등록이 되어 있다. 따라서 여러 환경에서 지원이 되며 (.NET, Ruby, Java, Node.js, Python, PHP 등) 수많은 회사의 인프라스트럭처에서 사용되고 있다. (구글, 마이크로소프트 등)
아래 블로그를 참고하여 작성하였습니다.
[JWT] 토큰(Token) 기반 인증에 대한 소개 | VELOPERT.LOG
소개 토큰(Token) 기반 인증은 모던 웹서비스에서 정말 많이 사용되고 있습니다. 여러분이 API 를 사용하는 웹서비스를 개발한다면, 토큰을 사용하여 유저들의 인증작업을 처리하는것이 가장 좋은
velopert.com
'Project' 카테고리의 다른 글
[Django]네이버 SMS 인증 (1) | 2021.09.06 |
---|