인증에 중요성에 대해서는 누구나 다 잘 알고 있기 때문에 설명할 필요가 없다.
JWT(Json Web Token)을 이용하여 인증을 처리하는 것이 좋은 방법이라고 하는데
JWT는 무엇인지, 다른 방법에는 어떤 것들이 있는지, 각각의 장단점은 어떤지 정리해보자.
인증(Authentication) vs 인가(Authorization)
정리하기에 앞서 용어에 대해 분명히 해두자. 발음은 잘 모르겠다.
인증 : 클라이언트가 자신이 주장하는 사용자인지 확인하는 과정
인가 : 클라이언트의 요청이 허가된 작업인지를 확인하는 과정. 즉 권한 부여
A. 서버 기반 인증 시스템(Session / Cookie)
서버 기반 인증 시스템은 로그인 시 세션 ID를 클라이언트에게 발급해주고 클라이언트는 요청 시마다 세션 ID가 담긴 쿠키를 헤더에 담아 보내는 방식이다. 상태를 유지해야 하므로 Stateful 한 구조를 가지고 있다.
[ 인증방식 ]
1. 사용자가 로그인 시 올바른 사용자임을 확인하고, 고유한 세션 ID 값을 부여하여 세션 저장소에 저장하고 클라이언트에게 발급해준다.
2. 클라이언트는 세션 ID를 받아 쿠키에 저장하고, 인증이 필요한 요청마다 쿠키에 세션 ID를 담아 헤더에 실어 보낸다.
3. 서버에서는 쿠키를 받아 세션 저장소와 비교해 올바른 요청인지 확인한다.
4. 인증이 완료되고 서버는 요청에 응답한다.
[ 장점 ]
- 중요한 정보는 서버에 있기 때문에 쿠키 자체(세션 ID)는 유의미한 값을 가지고 있지 않다.
[ 단점 ]
- 쿠키값 자체가 의미가 없다는 것은 안전해 보일 수 있으나, 해커가 훔친 쿠키를 이용해 HTTP 요청을 보내면 서버에서는 올바른 사용자가 보낸 요청인지 알 수 없다.(세션 하이재킹 공격)
-> 세션에 유효시간을 넣어줘야 한다. / B 방식도 마찬가지. - 세션을 저장해야 하므로 사용자가 늘어날 경우 서버의 RAM에 부하가 걸리게 된다. 이를 피하기 위해 데이터베이스에 저장하기도 하는데 이 역시 데이터베이스에 부하를 줄 수 있다.
- 시스템 확장이 어렵다. 단순한 사양 업그레이드가 아닌 더 많은 트래픽을 감당하기 위해 여러 프로세스를 돌리거나, 여러 대의 서버 컴퓨터를 추가하는 것을 의미한다.
B. 토큰 기반 인증 시스템(JWT)
토큰 기반 인증 시스템은 로그인 시 토큰을 발급해주고, 서버에 요청을 할 때 HTTP 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 하는 방식이다.
사용자의 인증 정보를 더 이상 서버에 저장하지 않고 클라이언트의 요청으로만 인가를 처리할 수 있으므로 Stateless 한 구조를 가진다.
JWT는 Json Web Token의 약자로 인증에 필요한 정보를 암호화시킨 토큰을 뜻한다.
세션/쿠키 방식과 유사하게 클라이언트는 Access Token(JWT)을 HTTP 헤더에 실어 서버로 보낸다.
A 방식과 가장 큰 차이점은 세션 저장소에 유저의 정보를 넣는 반면에 B 방식은 토큰 안에 유저의 정보를 넣는다는 점이다. 서버 측에서는 인증을 위해 암호화를 하느냐, 별도의 저장소를 이용하냐는 차이가 발생한다.
[ 인증방식 ]
1. 사용자가 로그인 시 올바른 사용자임을 확인하고, 클라이언트에게 Access Token(JWT)을 발급해준다.
2. 클라이언트는 전달받은 토큰을 저장해 두고, 인증이 필요한 요청마다 토큰을 HTTP 헤더에 담아 보낸다.
3. 서버에서는 암호화된 토큰을 복호화 해 올바른 요청인지 확인한다.
4. 인증이 완료되고 서버는 요청에 응답한다.
[ 장점 ]
- 간편하다. A 방식은 저장소의 관리가 필요하지만 Access Token을 발급해준 후 요청이 들어오면 검증만 해주면 되기 때문에 추가 저장소가 필요 없다. 즉 Stateless 하다.
- 쿠키를 사용함으로 인해 발생하는 취약점이 사라진다. 하지만, 토큰을 사용하는 환경에서의 취약점에 대비해야 한다.
- 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다. Ex) facebook, Google..
[ 단점 ]
- 이미 발급된 JWT를 돌이킬 수 없다. A 방식처럼 세션 저장소를 사용하는 경우에는 해당 세션이 악의적으로 사용될 경우 지워버리면 되지만, JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다
즉 유효기간이 지나기 전까지 실컷 털릴 수 있다.
-> 해결책에 대해서는 다음 글에서 정리 - JWT의 길이가 길다. 인증이 필요한 요청이 많아질수록 서버의 자원 낭비가 발생한다.
그래서..
서버 기반 인증 방식은 과거에 사용하던 방식이다.
서버 기반 인증 방식을 대체하기 위하여 등장한 것이 토큰 기반 인증 방식이지만 토큰을 사용한다고 해서 무조건 해킹의 위험에서 벗어난 것이 아니다.
다음 글에서는 JWT의 구조와 보안 전략에 대해 정리해보자.(Refresh Toekn)
이 글은 아래 사이트를 참고했습니다.
Refresh Token과 Sliding Session을 활용한 JWT 보안 전략 - blog.ull.im/engineering/2019/02/07/jwt-strategy.html
[JWT] 토큰(Token) 기반 인증에 대한 소개 - velopert.com/2350
쉽게 알아보는 서버 인증 1편 - https://tansfil.tistory.com/58?category=255594
'기타' 카테고리의 다른 글
[Docker] Docker 호스트에 원격으로 배포하기(docker compose 이용) (1) | 2021.12.18 |
---|---|
[MacBook]맥북에게 5000번 포트를 빼앗겼을때 - error: bind EADDRINUSE null:5000 에러 해결 (8) | 2021.12.18 |
SVN checkout시 SSL 에러 해결방법(CentOS) (0) | 2021.11.05 |
REST API란, RESTful API 설계 가이드 (0) | 2021.01.20 |
[Git] 깃허브란? Github 시작하기 - 1 (0) | 2020.06.18 |