구글 로그인 API를 구현해보려고 여러 블로그에서 정보를 찾다가 "토큰"이라는 말이 눈에 밟혔다.
생각해보니 이전에 세션과 쿠키에 대해 정리한 적은 있는데 토큰은 처음 듣는 말이었다. 그래서 토큰에 대해 알아보다가 사용자를 인증하는 방법 중에 하나라는 것을 알게 되었고, 그런데 세션을 사용하는 방법이 아닌 토큰을 사용하는 방법을 알게 되니까 우물 안의 개구리임을 다시 한번 실감했다. 그래도 이렇게 하나씩 알아간다는 것이 중요한 거 같다. 각설하고 바로 본론으로 들어가 보자!
1. 서버 기반 인증
기존의 서버 기반 인증은 서버 측에서 사용자들의 정보를 기억하고 있어야 한다.
사용자들의 정보를 기억하기 위해서는 세션을 유지해야 하는데, 이는 메모리, 디스크, 데이터 베이스 등을 통해 관리한다.
클라이언트의 요청이 있으면 서버는 클라이언트의 상태를 계속해서 유지하고 이 정보를 가지고 서비스를 제공한다. 이러한 서버를 Stateful 하다고 한다. 그래서 우리가 한 번 로그인을 하면 요청을 할 때마다 매번 로그인을 다시 할 필요 없이 서비스를 이용할 수 있는 것이다.
인증 과정
- 사용자가 로그인 시 올바른 사용자임을 확인하고, 세션 ID를 부여해서 저장하고 클라이언트에게 전송한다.
- 사용자가 서버에 요청할 때, 세션 ID가 포함된 쿠키를 같이 보낸다.
- 서버는 받은 쿠키의 값과 저장한 값이 같은지 확인한다.
- 같다는 확인이 완료되면 서버는 요청에 응답한다.
[장점]
- 중요한 정보는 서버가 가지고 있기 때문에 사용자가 가지고 있는 쿠키 자체에는 유의미한 값을 가지고 있지 않다.
[단점]
- 서버에 세션을 저장하므로 사용자가 많아지면 그만큼 과부하를 줄 수 있고, 시스템 확장이 어렵다는 문제점을 가지고 있다.
2. 토큰 기반 인증
서버 기반 인증의 단점을 보완하기 위해 토큰 기반 인증이 나왔다. 인증받은 사용자에게 토큰을 발급해주고,
서버에 요청을 할 때마다 HTTP 헤더에 토큰을 함께 보내서 인증된 사용자가 맞는지 유효성 검사를 하는 것이다.
사용자의 정보를 저장할 필요가 없고 사용자의 요청으로만 인가 처리를 하므로 Stateless 한 구조를 가지게 된다.
이러한 토큰 기반 인증의 방식으로 손쉽게 시스템을 확장할 수 있게 되었다.
인증 과정
- 사용자가 아이디와 비밀번호를 입력하고 로그인을 한다.
- 서버 측에서 해당 정보를 검증한다.
- 정보가 맞다면 사용자에게 Signed 토큰을 발급한다.(여기서 Signed란? 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 Signature를 가지고 있다는 것을 의미한다.)
- 사용자는 해당 토큰을 저장하고 서버에 요청을 할 때마다 해당 토큰을 HTTP 헤더에 포함시켜 전달한다.
- 서버는 토큰을 검증하고 응답에 요청한다.
[장점]
- 토큰을 발급해준 뒤 요청을 통해 들어온 토큰에 대한 검증만 하면 되므로 서버 인증 기반처럼 저장소가 필요 없다.
- 쿠키를 사용하면서 생기는 문제점이 사라진다.
- 확장성이 매우 좋다. 토큰을 사용하는 다른 인증 시스템에 접근이 가능하다. ex) Google 등...
[단점]
- 서버 기반 인증처럼 따로 저장소가 있는 게 아니기 때문에 이미 발급된 토큰은 유효 기간이 만료할 때까지 사용해야 한다. 즉, 토큰이 털리게 되면 유효 기간이 만료할 때까지 계속 악의적으로 사용될 수 있다.
- 토큰은 길이가 길기 때문에 인증이 필요한 작업이 많아지면 서버의 자원 낭비가 발생한다.
※ 도움을 주신 분들
'Web' 카테고리의 다른 글
| Proxy란 ? (0) | 2022.06.20 |
|---|---|
| JWT(Json Web Token)란? (0) | 2022.06.16 |
| REST란? REST API 와 RESTful API (0) | 2022.06.13 |
| 캐시(Cache) (0) | 2022.05.23 |
| 쿠키와 세션 (0) | 2022.05.19 |